Ошибка доступа к MS с MySQL - PullRequest
0 голосов
/ 01 июля 2018

Я работал над приложением, которое использует MS Access 2010 и Oracle. Сейчас я работаю над использованием моего sql 5.7 вместо oracle.

Но код в доступе ms содержит recordset.edit, а затем 2 оператора set, за которыми следует recordset.update. recordset.edit recordset.Fields(22).value=1 recordset.update

Это дает ошибку времени выполнения 3197. Вы и другой пользователь пытаетесь изменить одни и те же данные одновременно.

Я попытался сопоставить все типы данных. Но, похоже, ничего не работает. Тем не менее я получаю ту же ошибку.

Ценю вашу помощь. Заранее спасибо

1 Ответ

0 голосов
/ 03 июля 2018

Это «другое» сообщение пользователя часто вводит в заблуждение, и фактически другой пользователь не обновил запись.

Две вещи, которые нужно проверить:

Если какое-либо обновление sql или код набора записей «могут» обновить текущую запись, над которой вы работаете, то принудительно запишите на диск, и, следовательно, не существует ожидающих обновлений:

Например:

If me.Dirty = True then me.Dirty = false.

YOUR code here such as above is now called/run

Вторая распространенная проблема - пустые столбцы. Это часто приводит к путанице в доступе, и поэтому вам необходимо убедиться в том, что на уровне SERVER у вас есть набор по умолчанию для таких столбцов (значение 0 для сервера sql - не уверен, что то же самое для MySQL). Так что это ОБЯЗАТЕЛЬНАЯ проблема с проверкой.

Далее:

Убедитесь, что в рассматриваемой таблице есть PK, и вы должны добавить версию строки (метка времени). Этот тип столбца НЕ следует путать с датой или столбцом для хранения текущего времени - это столбец версии строки. Поэтому добавьте столбец отметки времени, убедитесь, что столбец PK существует, и убедитесь, что в любом столбце битов (true / false) в таблице есть значение по умолчанию. Если существующие битовые столбцы имеют нулевые значения, выполните запрос на обновление, чтобы установить для них все false (0).

После внесения изменений в таблицу (если требуется), затем заново свяжите все таблицы доступа.

Вышеуказанное должно охватывать 99% случаев, когда вы получаете это «другое» сообщение пользователя, когда на самом деле вы уверены, что это не другой пользователь.

...