БД связанного доступа "запись была изменена другим пользователем"
Я поддерживаю многопользовательскую базу данных Access 2000, связанную с базой данных MSSQL2000, а не написанную мной.
Дизайн базы данных очень плохой, так что вам придется терпеть меня.
В форме "Клиент" есть поле "Customer_ID", которое по умолчанию должно получить следующий доступный идентификатор клиента, но у пользователя есть возможность переопределить этот выбор существующим идентификатором клиента.
Теперь поле Customer_ID не является PK таблицы Customer. Это также не уникально.
Если клиент дважды звонит, чтобы отправить работу, таблица получит две записи, каждая с одинаковой информацией о клиенте и одинаковым идентификатором клиента.
Если пользователь создает новый билет, Access выполняет быстрый поиск следующего доступного идентификатора клиента и заполняет его. Но запись не сохраняется. Очевидно, проблема - редактирование двух пользователей должно отслеживать работу друг друга, чтобы они не дублировали идентификатор клиента.
Поэтому я хочу изменить кнопку "Новая запись", чтобы она сохраняла заявку сразу после создания новой.
Проблема в том, что когда я проверяю изменения, я получаю сообщение "Эта запись была изменена другим пользователем, так как вы начали ее редактировать".
Определенно нет других пользователей в БД. "Другой пользователь" был, вероятно, моим принудительным сохранением.
Есть идеи?
9 ответов
Посмотрите на вашу связанную таблицу в SQL Server 2000. Есть ли в ней поле, содержащее тип данных бит? Access выдаст вам это сообщение об ошибке в сценарии со связанной таблицей, если у вас есть битовое поле, которое не имеет значения по умолчанию.
Возможно, это не то, что не так в вашем случае, но я испытал то же самое в базе данных Access 2007 и отследил проблему в битовом поле без значения по умолчанию.
Я видел это поведение раньше, и это исправило это для меня:
Попробуйте добавить поле TimeStamp в таблицу (просто добавьте это поле и обновите связанные таблицы. Вам не нужно заполнять это поле какими-либо данными).
Ошибка, которую вы получаете, обычно возникает, когда:
- вы редактируете запись в форме, а форма грязная (то есть редактирование не сохранено),
А ТАКЖЕ
- вы запускаете код, который использует DAO или ADO для запуска SQL для обновления той же записи.
Для Jet это два "пользователя", потому что это две разные операции редактирования. Базовая таблица была обновлена обновлением SQL, а данные в буфере формы устарели.
Обычным решением является принудительное сохранение перед запуском обновления SQL:
If Me.Dirty Then
Me.Dirty = False
End If
[run your SQL update here]
Но если вы используете формы для редактирования записи, вы должны делать все обновления в форме, а не прибегать к SQL для обновления.
Ситуация, которую вы описываете с генерацией собственной последовательности, должна быть сделана следующим образом:
пользователь нажимает кнопку NEW RECORD.
вычислите следующее значение последовательности и сохраните его в переменной.
вставить новую запись с этим значением последовательности через SQL INSERT.
4а. если ваша форма связана со всеми записями в таблице, запросите форму редактирования данных (при условии, что кнопка НОВАЯ ЗАПИСЬ находится на форме, где пользователи редактируют данные), и используйте навигацию по закладкам для перехода к новой записи со значением последовательности, которое Вы сохранили в переменной в шаге 2.
4b. Если ваша форма не связана со всеми записями (как это должно быть, если это хорошо спроектированная база данных), вы просто измените источник записей формы, чтобы загрузить только новую запись.
Другая альтернатива - избегать SQL INSERT и запроса (или сбрасывать источник записей) и просто добавлять новую запись в существующую форму, устанавливать в поле последовательности новое значение и немедленно сохранять запись.
Ключевым моментом является то, что для того, чтобы это работало в многопользовательской среде, запись должна быть сохранена, как только ей присвоено значение последовательности - вы не можете оставить запись висящей там несохраненной, потому что это означает, что идентичное значение последовательности доступно для других пользователей, которые просто запрашивают катастрофу.
Это старый вопрос, с которым я столкнулся в Google, поэтому я отправлю свой ответ.
В драйвере ODBC обязательно включите управление версиями строк. Если таблица уже находится в Access, вам придется удалить ее и повторно связать с исходной таблицей.
Вы должны быть в состоянии определить, включено ли управление версиями строк, поскольку Access должен добавить в таблицу столбец с именем xmin,
Я неоднократно просматривал этот и несколько других постов, чтобы найти решение этой проблемы. У меня есть база данных MS Access, связанная с базой данных MySQL. Проблема была вызвана существующим триггером BeforeUpdate в MySQL phpmyadmin. В phpmyadmin перейдите к структуре таблицы, и внизу экрана вы увидите триггеры.
Я бы отслеживал, переопределил ли пользователь новый customer_id своим собственным значением. Если они этого не сделали, то ваше приложение должно иметь возможность проверять наличие дубликатов перед сохранением и просто самовращаться, и пользователь не возражает против выбора значения по умолчанию. Может быть, даже какой-то индикатор для пользователя, что вам нужно было автоматически выбрать другое значение.
Эту ошибку также можно вызвать, если таблица SQL Server содержит столбец datetime2 (в моем случае это значение по умолчанию sysdatetime()). Изменение типа данных обратно к datetime по умолчанию current_timestamp останавливает ошибку.
Наши проблемы заключались в том, что клиентский интерфейс доступа пытался сохранить int (да / нет) в поле mssql bit (0/1). Изменение базы данных mssql на поля int работало как чудо.
Я только столкнулся с другой ситуацией, которая генерирует эту ошибку. В таблице mysql у меня было два столбца даты, которые изначально имели значение по умолчанию "0000-00-00". Позже он был изменен на значение по умолчанию NULL, но многие строки сохранили значение "0000-00-00". Мне пришлось вручную сбросить значения в NULL, чтобы остановить ошибку.
Потребовалось много времени, чтобы выяснить, что вызвало ошибку, HTH кто-то еще.
У меня тоже была такая же проблема. Я пытался обновить в таблице с помощью Spring MVC и Hibernate. В моем случае столбец версии в таблице содержит значение больше 1(т.е. 3), однако информация об обновлении в моем запросе на обновление имела значение версии 1.