В таком контексте нужна проверка корректного завершения каждой команды модификации.

-) INSERT-SQL может НЕ выполнить вставку (много причин), как следствие, REPLACE будет выполнен не туда
-) Собственно REPLACE может НЕ выполнить модификацию (тоже много причин)

Т.е. вопрос даже не в блокировках (хотя тоже есть опасность "мертвых" блокировок, но для этого есть SET REPROCESS), а в корректности выполнения команд.

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


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

Разрешение конфликтов совместного доступа сведено к одному программному узлу (TableUpdate()). А при выполнении собственно команд модификации надо следить только за ошибками корректной модификации данных и уже не обращаешь внимания на проблемы совместного доступа.

LevranТогда наверное имеет смысл включить буферизацию и для третьей таблицы (в которой выполняется replace).
Ну, да, буферизировать надо все таблицы, которые собственно модифицируются. Хотя, возможны исключения из этого правила в конкретной задаче.

LevranВ этом случае даже не надо проверять старое значение и новое, чтобы определить выполнился ли replace. Потому что все моменты связанные со сбросом буфера в таблицу берет на себя FoxPro (читай функция TableUpdate()). Так?
Не совсем. При буферизации нет никакого контроля на значение данных. Проверяется сам факт модификации данных. Но ведь вполне возможно, что пользователь изменил какое-то поле, а потом спохватился и вернул старое значение. При этом, хотя поле было модифицировано, но его значение по сути не изменилось. Если для Вас это имеет принципиальное значение, то такую ситуацию следует дополнительно контролировать.

LevranИ вообще, насколько эффективно с точки зрения безопасности и надежности использование транзакции в FoxPro?
Насколько эффективно и безопасно работать с таблицами DBF? Вопрос того же уровня.

LevranНе проще ли старым дедовским методом: блокирую все таблицы, вставляю, снимаю блокировку... Понятно, что делать я так не буду, но всё-таки хочется услышать Ваше мнение.
Суть транзакции - это внесение изменений по принципу "Все или ничего". Т.е. либо ВСЕ изменения будут внесены в базу данных, либо не будет внесено НИКАКИХ изменений.

Если жы Вы будете работать без транзакции через блокировку таблиц, то пондобиться самостоятельно писать код по откату внесенных изменений, если, например, в первую таблицу внесли изменения, а во вторую не удалось. Или не изменились часть записей в одной таблице.

LevranВсе дело еще в том, что блокировать "надолго" записи у меня возможности (есть свои причины), именно вследствии этой причины я и пришел к использованию транзакции, хотя не очень уверен в обоснованности ее использования.
Не совсем понял: Вы можете или нет блокировать запись "надолго"?

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

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

Блокировка данных будет производится только в момент сброса изменений (по TableUpdate()). В это же время производится и разрешение конфликтов совместного доступа. Если действительно была модификация одних и тех же данных (второй параметр в команде TableUpdate()+AERROR()- код ошибки 1585)

Буферизация и транзакция - это 2 разных процесса. Выбор типа буферизации никак не может повлиять на логику работы транзакции.

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

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

При оптимистической буферизации в процессе редактирования буфера данные остаются НЕ заблокированными. Блокировка осуществляется только в момент сброса буфера (например, по команде TableUpdate()).

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

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

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

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

Если опустить чисто психологическую проблему (пользователь желает редактировать, а его не пускают), то проблема в том, что блокировка данных - это технически опасный момент. В том смысле, что сбой питания или обрыв соединения в этот момент может привести к порче структуры таблицы (но может и НЕ привести. Как повезет). Более опасным в этом смысле является только прямое редактирование данных неопределенно долгое время.

&&&&&
А НЕ ПОДСКАЖЕТЕ ЛИ ПО-КОНКРЕТНЕЙ НАСЧЕТ РАЗБОРКИ ПОЛЕТОВ...
ИМХО - если НЕ разбирать их - то в базу запишутся данные того, кто последний нажал СОХРАНИТЬ...
Но ведь это порой не хорошо... как быть тогда?
Посмотрите парой постов выше:


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

Ни в коем случае нельзя оставлять "подвешенную" тарнзакцию на момент ожидания реакции пользователя!

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