как отслеживать не поменял-ли кто другой данные пока я их меняю

Существует такая вещь, как оптимистическая буферизация и второй параметр в команде TableUpdate()

* Пользователь завершил редактирование в режиме оптимистической буферизации и нажал кнопку "Сохранить"

IF TableUpdate(.F.,.F.)=.F.
* Пока пользователь курил, другим пользователем были изменены те же данные.
* Деламе дополнительный запрос пользователю и если он решил писать поверх

TableUpdate(.F.,.T.)
ENDIF

Если на таблицу установлен любой режим буферизации, то любые модификации производятся не сразу с таблицей, а записываются в некий "буфер".

Т.е. ты выполняешь все обычные команды по модификации (INSERT-SQL, REPLACE, UPDATE-SQL), но они модифицируют не непосредственно исходную таблицу, а ее буфер.

В режиме строковой буферизации (2 или 3) сброс буфера происходит:

-) По команде TableUpdate()
-) При переходе на другую запись
-) При закрытии таблицы

В режиме табличной буферизации (4 или 5) сброс буфера происходит

-) Только по команде TableUpdate() и никак иначе

Откат внесенных в буфер изменений и очистка буфера происходит по команде TableRevert()

Это значит, что при установленном режиме буферизации ты работаешь с таблицами как обычно. Однако чтобы внесенные изменения попали в исходную таблицу необходимо сбросить буфер этой таблицы.

Проверить факт модификации данных при табличной буферизации можно по команде GetNextModified(), а в пределах одной записи по GetFldState().

При работе в режиме табличной буферизации следует иметь в виду, что сброс буфера осуществляется по одной строке за раз. Это значит, что если в процессе сброса буфера произойдет ошибка, то хотя выполнение команды TableUpdate() будет прервано, но тем не менее все ранее сброшенные данные (сброшенные ДО возникновения ошибки) попадут в итоговую таблицу.

Как следствие, если предполагается сброс более одной записи, то команду TableUpdate() следует окружать транзакцией.

Если в процессе сброса буфера по команде TableUpdate() произошла ошибка, то никакого сообщения об ошибке не появится. Просто команда TableUpdate() вернет .F. Анализ причины ошибки следует выполнить при помощи функции AERROR().

Итого, примерный код кнопки "Сохранить" в режиме оптимистической табличной буферизации (5)

Датасессия на форме, в которой редактируется запись какая должна быть в Вашем примере?

Без разницы.

Private DataSession - это симуляция многопользовательского доступа для одного пользователя (с некоторыми ограничениями). Правда, я не проверял будет ли конфликт совместного доступа при одновременной правке в 2 формах одного приложения в Private DataSession. Но в одном приложении ты можешь организовать глобальный объект для отслеживания подобных ситуаций.

Если правка будет осуществлятся только в модальных формах, то ввобще никаких вопросов не возникнет.

форма "сама" в приватной сессии открывает
Это Вам так кажется. Реально выполняются те же команды USE. Просто их не надо явно прописывать в коде.

Код написан из предположения, что данные правятся разными пользователями (или разными экземплярами программы на одном компьютере)

Да, в коде, разумеется, вместо слова CONTINUE надо написать LOOP. Опечатка

автор1)Уважаемый Владимир, скажите а какие изменения произойдут в приведенном коде для пессимистической буферизации таблицы(4),

При пессимистической буферизации нет смысла во втором параметре в команде TableUpdate(). Т.е. ситуация, когда в процессе редактирования одним пользователем другой изменил те же самые записи в принципе невозможна. Следовательно, нет необходимости в цикле.

автора также на Ваш взгляд нужна ли кнопка "Сохранить" при буферизации записей (2,3)?

Зависит от того, как именно происходит редактирование - построчно (набор TextBox) или групами в Grid. Кроме того, следует уточнить постановку задачи. Возможно требуется автоматическое сохранение безо всяких кнопок.

автор2)По Вашему мнению какую буферизацию лучше(надежнее) использовать, я так понимаю это зависит прежде всего от размера таблицы?

Нет, это прежде всего зависит от постановки задачи.

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

При оптимистической буферизации - нет проблем начать вносить изменения, но есть проблемы в момент сохранения внесенных изменений.

При буферизации таблиц - нет проблем с сохранением внесенных изменений, поскольку этот процесс полностью управляется программистом.

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

Я правильно понимаю, что если идет редактирование для набора TextBox-ов, то лучше использовать буфферизацию записей, а если Grid - то табличную буфферизацию?

Повторюсь. Это зависит от постановки задачи.

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

2)Пессимистическая буфферизация - это одно и тоже что если бы я на, допустим, нажатие кнопки формы "Редактировать" вставил RLOCK() [LOCK()],
т.е. при этой буфферизации происходит блокировка записи(таблицы)?

Да. Только если давая команды RLOCK() явно Вы можете проконтролировать факт их выполнения, то при пессимистической буферизации придется отлавливать сообщение об ошибке (ON ERROR или Form.Error())

Оптимистическая буферизация делает попытку заблокировать запись только в момент сброса буфера.