Aktualizowanie bazy danych SQLite za pośrednictwem tabeli połączonej ODBC w Access

Question

Mam problem z bazą danych SQLite. Używam SQLite ODBC z http://www.ch-werner.de/sqliteodbc/ zainstalowana w wersji 64-bitowej i stworzył ODBC z tymi ustawieniami:

otworzę moje bazy danych Access oraz link do źródła danych. Mogę otworzyć tabelę, dodawać rekordy, ale nie mogę usuwać ani edytować żadnych rekordów. Czy jest coś, co muszę naprawić po stronie ODBC, aby na to pozwolić? Błąd, który pojawia się podczas próby usunięcia rekordu, to:

Silnik baz danych Microsoft Access zatrzymał proces, ponieważ Ty i inny użytkownik próbujesz zmienić te same dane w tym samym czasie.

Kiedy edytować rekord uzyskać:

Rekord został zmieniony przez innego użytkownika od rozpoczęcia edycji. Jeśli zapiszesz rekord, nadpiszesz zmieniony, którego dokonał inny użytkownik.

Zapisanie zapisu jest wyłączone. Dostępne jest tylko kopiowanie do schowka lub upuszczanie zmian.

Answer 1

Moja pierwsza próba odtworzenia problemu nie powiodła się. Użyłem następujących w moim teście 32-bitowym VM:

• Access 2010
• SQLite 3.8.2
• SQLite ODBC 0,996

stworzyłem i zaludnionych tabeli testowej [TBL1] jak udokumentowano here. Stworzyłem połączoną tabelę programu Access i po wyświetleniu monitu wybrałem obie kolumny ([jedna] i [dwie]) jako klucz główny. Kiedy otworzyłem połączoną tabelę w widoku arkusza danych, mogłem dodawać, edytować i usuwać rekordy bez żadnych incydentów.

Jedyną różnicą, którą mogę zobaczyć między moją instalacją a twoją (oprócz tego, że jestem na 32-bitowym i 64-bitowym) jest to, że w ustawieniach DSN ODBC opuściłem ustawienie Sync.Mode na jego domyślnym poziomie wartość NORMAL, a Twoja wydaje się być ustawiona na OFF.

Spróbuj ustawić swoje Sync.Mode na NORMAL i sprawdź, czy to ma znaczenie.

Edit Re: Komentarze

Rozwiązaniem w tym przypadku był następujący:

Możliwym Rozwiązaniem byłoby stworzenie nowej tabeli SQLite z wszystkich tych samych kolumn plus nowego INTEGER PRIMARY KLUCZ KEY, który Access "zobaczy" jako AutoNumber. Możesz utworzyć unikalny indeks na (co jest obecnie) w pierwszych czterech kolumnach, aby zapewnić, że pozostaną unikalne, ale nowa nowa "tożsamość" (ROWID) kolumna jest tym, co Access użyłby do zidentyfikowania wierszy dla operacji CRUD.

Answer 2

Ja też miałem ten problem. Mam tabelę z kluczem podstawowym w polu VARCHAR (30) (TEXT).

Dodanie kolumny INTEGER PRIMARY KEY nie pomogło w ogóle. Po wielu testach odkryłem, że problem dotyczy pola DATETIME, które miałem w tabeli. Usunąłem pole DATETIME i mogłem zaktualizować wartości rekordów w widoku arkusza danych MS Access.

Teraz wszystkie pola DATETIME, których potrzebuję w SQLite, deklaruję jako VARCHAR (19), więc niektórzy uzyskują dostęp poprzez ODBC jako tekst. Nie doskonały, ale działa. (I oczywiście SQLite nie ma prawdziwego pola typu DATETIME, tak więc TEKST jest w porządku i przekonwertuje OK)

Potwierdziłem, że jest to problem z konwersją numerów. Z pustego pola daty, mogę dodać czas 01-01-2014 12:01:02 poprzez dostęp widoku arkusza danych, gdybym wtedy spojrzeć na wartości w SQLite sekundy zostały zaokrąglone: ​​

sqlite> SELECT three from TEST where FLoc='1020'; 
2014-01-01 12:01:00.000 

SYNCMODE powinien być również NORMALNY, a nie WYŁĄCZONY.

Aktualizacja: Jeśli masz jakieś pól tekstowych o określonej długości (np foo VARCHAR (10)) i zawartości pól zawiera więcej znaków niż definicja pola (co pozwala SQLite) MS-Access będzie również barf kiedy próbuje zaktualizować dowolne pól w tym wierszu.

Answer 3

Przeszukałem wszystkie podobne posty, ponieważ miałem podobny problem z SQLite połączonym przez ODBC z Access. Miałem trzy stoły, z których dwa były dozwolone, ale trzeci nie. Trzeci miał pole DATETIME i kiedy zmieniłem typ danych na pole TEXT w oryginalnej bazie danych SQLite i zsynchronizowałem się z dostępem, mogłem edytować tabelę. Tak więc dla mnie zostało to potwierdzone jako problem z polem DATETIME.