Обновление базы данных SQLite через связанную с ODBC таблицу в Access

У меня проблема с базой данных SQLite. Я использую SQLite ODBC от http://www.ch-werner.de/sqliteodbc/ Установил 64-разрядную версию и создал ODBC с этими настройками:

Я открываю базу данных Access и ссылаюсь на источник данных. Я могу открыть таблицу, добавить записи, но не могу удалить или отредактировать записи. Есть ли что-то, что мне нужно исправить на стороне ODBC, чтобы это разрешить? Ошибка при попытке удалить запись:

Механизм базы данных Microsoft Access остановил процесс, потому что вы и другой пользователь одновременно пытаетесь изменить одни и те же данные.

Когда я редактирую запись, я получаю:

Запись была изменена другим пользователем с момента ее начала. Если вы сохраните запись, вы перезапишите измененный другой пользователь.

Сохранить запись отключена. Доступна только копия в буфер обмена или изменения кавычек.

Ответ 1

Моя первоначальная попытка воссоздать вашу проблему была неудачной. Я использовал следующее на моей 32-разрядной тестовой VM:

Доступ 2010
SQLite 3.8.2
Драйвер ODBC SQLite 0.996

Я создал и заполнил тестовую таблицу [tbl1], как описано здесь. Я создал таблицу, связанную с доступом, и по запросу я выбрал оба столбца ([один] и [два]) в качестве основного ключа. Когда я открыл связанную таблицу в представлении Datasheet, я смог добавлять, редактировать и удалять записи без инцидентов.

Единственное различие, которое я могу видеть между моей установкой и вашим (кроме того, что я нахожусь на 32-разрядной версии и вы на 64-битной основе), заключается в том, что в настройках DSN ODBC я оставил параметр Sync.Mode на своем значение по умолчанию NORMAL, тогда как для вас установлено значение OFF.

Попробуйте установить Sync.Mode на NORMAL и посмотрите, не имеет значения.

Изменить re: комментарии

Решение в этом случае было следующим:

Одним из возможных способов решения проблемы было бы создание новой таблицы SQLite со всеми одинаковыми столбцами плюс новый столбец INTEGER PRIMARY KEY, который Access будет "видеть" как AutoNumber. Вы можете создать уникальный индекс на (в настоящее время) первых четырех столбцах, чтобы убедиться, что они остаются уникальными, но новый новый столбец "identity" (ROWID) - это то, что Access будет использовать для идентификации строк для операций CRUD.

Ответ 2

У меня тоже была эта проблема. У меня есть таблица с первичным ключом в поле VARCHAR (30) (TEXT).

Добавление столбца INTEGER PRIMARY KEY не помогло. После многих тестов я обнаружил, что проблема связана с полем DATETIME, который я имел в таблице. Я удалил поле DATETIME, и мне удалось обновить значения записей в представлении данных MS-Access.

Итак, теперь любые поля DATETIME, которые мне нужны в SQLite, я объявляю как VARCHAR (19), поэтому некоторые из них попадают в Access через ODBC в виде текста. Не идеально, но он работает. (И, конечно же, SQLite не имеет реального типа поля DATETIME, так что TEXT просто отлично и преобразует OK)

Я подтвердил, что это проблема с преобразованием номера. С пустым полем DATETIME я могу добавить время 01-01-2014 12:01:02 через представление Access datasheet, если я затем посмотрю на значение в SQLite, секунды были округлены:

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

SYNCMODE также должен быть NORMAL, а не OFF.

Update: Если у вас есть текстовые поля с определенной длиной (например, foo VARCHAR (10)), а содержимое поля содержит больше символов, чем определение поля (которое разрешает SQLite). MS-Access также будет barf при попытке обновить любое из полей на этом строки.

Ответ 3

Я искал все похожие сообщения, поскольку у меня была аналогичная проблема с SQLite, связанным через ODBC для доступа. У меня было три стола, два из них разрешили редактирование, а третий - нет. У третьего есть поле DATETIME, и когда я изменил тип данных в поле TEXT в исходной базе данных SQLite и перешел на доступ, я мог бы редактировать таблицу. Поэтому для меня это было подтверждено как проблема с полем DATETIME.