кто последний нажал бновить, такие и данные...
А вот это совсем странно. В аксесе ругается на то, что данные были изменены другим пользователем. Это похоже на отсутствие блокировки ваапсче, но ведь так не бывает?
Access ругается потому что он запоминает состояние записи при её считывании в форму и при обновлении сравнивает то что считал с тем что в базе и ругается если находит отличия. Блокировка на уровне данных здесь не при чем. И при работе через ADO если не предпринимать таких же мер (сравнение старых данных с текущими данными на сервере) Андрей абсолютно прав - кто последний сохранит того и данные. И блокировки - они есть. Только налагаются на короткое время (как и должно быть) - если LockEdits:=dbOptimistic то блокировка на изменяемые данные налогается в момент вызова метода .Update и сразу после сохранения снимается- если LockEdits:=dbPessimistic - то в момент вызова .Edit (такого метода в ADODB.Recordset уже нет, я имею ввиду - в момент начала редактирования данных) и удерживается до вызова метода .Update.
А вообще имхо с такого рода блокировками надо бороться потому как это снижает возможность парралельной работы многих пользователей, а очереди организовывать другими методами. Например с пом. sp_getapplock в MsSQL Server 2000 (или написать аналоги для более ранних версий или для mdb). Главное при организации такого рода блокировок незабыть реализовать механизм снятия блокировки в случае если пользователь неожиданно "отвалился" от базы (ну комп выключил кнопкой пауер).
Вот здесь эта тема обсуждалась:
Аналог процедур sp_getapplock и sp_releaseapplock для Ms SQL Server 7.0

2ЛП:
DAO не стал проверять - проверил то, что я говорил - ADODB.Recordset. Оказывается, говоря: И при работе через ADO если не предпринимать таких же мер (сравнение старых данных с текущими данными на сервере) ... я ошибался - самому таких мер предпринимать не надо - ADOшный рекордсет тоже их предпринимает сам :). Как это работает - (по инфе из MSDN - статья Rob Macdonald "An Update on Updating") - при выполнении изменения через рекордсет:

реально на SQL Server уходит запрос:
UPDATE "Customers" SET "ContactName"= НОВОЕЗНАЧЕНИЕ
WHERE "CustomerID"= ? AND "ContactName"= СТАРОЕЗНАЧЕНИЕ
и в случае, если старое значение поля ContactName изменилось - то просто запись не находится и выдается сообщение об ошибке:

вот такая вот механизма ;)

В сообщении об ошибке блокировка не упоминается, но скорее всего это она.
:)
Скорей всего нет - не она. Это не блокировка, а просто проверка, которую выполняет сам объект Recordset перед обновлением. Блокировок на сервере (или в ldb для mdb с данными) после Update не остаётся. Они существуют короткое время (при оптимистической блокировке).
вот из тогоже MSDN:
adLockOptimistic - Indicates optimistic locking, record by record. The provider uses optimistic locking, locking records only when you call the Update method.
adLockPessimistic - Indicates pessimistic locking, record by record. The provider does what is necessary to ensure successful editing of the records, usually by locking records at the data source immediately after editing.
В общем, должно DAO (Jet) само отслеживать такие ситуации. Если в дельфях BDE этого не делает - ну тады вопрос к борланду.
Да, соглашусь, если объект перед обновлением выдает сообщение о том, что с момента считывания данные изменились - результат достигнут и в общем то неважно за счет чего - за счет блокировок или за счет сравнения считанных данных с данными на сервере в момент обновления.
(хотя немного всётаки важно - например проверка может не сработать или занять много времени если в таблице есть несколько полей типа Text, Image. Зная механизм в этих случаях можно облегчить жизнь рекордсету, добавив в таблицу поле типа TimeStamp - в случае его наличия проверка изменения будет производиться по нему (сам не проверял, но судя по всему это так)).
ЗЫ: я про случай, если данные находятся на Ms SQL Server.