Вопрос повторяется с завидной регулярностью. Почитайте по ссылке

http://www.sql.ru/forum/actualthread.aspx?tid=127239#1005175

Там речь идет о Remote View, но для Local View все абсолютно то же самое.

Несколько тезисов:

-) Не надо блокировать запись вручную
-) О том, что запись изменена другим пользователем можно узнать при попытке сброса своих изменений

RaufMА как же быть насчет:
"сообщать пользователю перед редактированием данных, что строка уже редактируется другим".
А зачем?

Когда возникают подобные вопросы надо начинать не с того, чтобы сразу пытаться их решить, а с прямо противоположного:

Что будет, если два пользователя "одновременно" редактируют одну и ту же запись?

Ну, в самом процессе редактирования ничего плохого не будет. Они друг другу не мешают. Проблему будут в момент сброса изменений. А вот тут масса "тонких" моментов:

-) Пользователи редактировали разные поля одной и той же записи - никаких проблем. Разрешаем модификацию без ограничений.

-) Пользователи редактировали общие поля, но это были не "критичные" поля. Ну, например, они редактировали Фамилию клиента. Вряд ли имеет смысл что-то запрещать. Скорее, тоже можно разрешить модификацию без ограничений

-) Пользователи редактировали общие "критичные" поля.

Для начала, следует предупредить того, кто начал сброс позднее, что за время пока он редактировал кто-то другой уже вне сизменения и спросить писать ли поверх.

Далее. Модификация таких "критичных" полей обычно собровождается кучей условий, который прописываются в триггерах. Т.е. вообще-то, это изменение может быть отклонено.

В случае запрета на модификацию выдаем сообщение пользователю и он принимает решение: внести другие изменения, обновить данные или отказаться вообще от модификации данной записи.

Следующий вопрос, который надо себе задать: А насколько вообще вероятна подобная ситуация?

Как правило, пользователи не лезут в "чужие" данные. Им и так хватает работы. Разумеется, если это не обусловлено спецификой задачи.

Т.е. в большинстве случаев, ситуация редактирования разными пользователями одной и той же записи маловероятна. И забивать себе голову сложными алгоритмами "разруливания" подобных ситуаций не имеет смысла. Либо просто писать поверх, либо полный откат и повторный ввод для второго пользователя.

RaufMПосле редактирований, удалений записей и добавления новых что-то не получается обновить данные на клиенте, т.е. хотелось бы видеть самые актуальные данные, что нужно сделать (применительно к вышеописанной задаче)
Не совсем понял проблему. Если дается команда Requery("MyView"), то обновляется содержимое MyView полностью. Т.е. берутся актуальные данные, те, что сейчас реально в базе данных. В этот момент клиент и видит, что есть реально в базе данных.

RaufMя так и делал Requery(...).
Но срабатывает только со второго раза.
Т.е., редактирую запись на одной машине, сохраняю, сообщается Requery(...)=1, в это время на другой машине - изменения не отражены, даю на ней Requery(...) - тогда появляются изменения, если не даю - ничего. Может быть где-то должно быть типа AutoRefresh или использовать SET REFRESH TO nSeconds, но это наверное будет сильно напрягать процессор?
А ты еще обижаешся, почему часто посылают... читать HELP?

View - это по сути результат выполнения команды Select-SQL. Т.е. это не исходные данные . Это выборка (некая копия) из исходных данных, которая существует только у одного клиента.

Выполни на своей машине простой запрос по любой таблице вроде

SELECT * FROM MyTable INTO CURSOR curTest NOFILTER

А теперь измени содержимое этой самой таблицы MyTable. Тебя ведь не удивляет, что содержимое curTest никак не изменилось? Откуда тогда такое недоумение по поводу View?

Чтобы изменилось содержимое curTest, надо выполнить этот запрос еще раз . Т.е., применительно к View, надо выполнить Requery() после изменения данных.