В FP блокировку снимет файловый сервер. Через некоторое время. Если клиент "отвалился", установив блокировку, ничего страшного не случится, за исключением того, что в течение времени, пока файл-сервер ее не снимет, запись таблицы будет недоступна для операции записи. Кстати, наложение блокировки никогда не запрещает доступа по чтению.
Транзакции в VFP, конечно, есть, но они не такие, как в "серьезных" серверах БД. И если с точки зрения записи в таблицы БД они способны обеспечить должный уровень контроля и целостность при сохранении единого блока операций, то с точки зрения чтения не все так хорошо. Насколько я знаю, нет никакой гарантии, что в выборку одного пользователя не попадут данные из еще не до конца проведенной транзакции другого. Если не принять специальные меры. А именно, в особо критичных случаях придется ставить блокировку и перед чтением , а не только при записи. К счастью, такие случаи можно пересчитать по пальцам. ;-)
Хочу заметить, что в старых версиях FP вообще не было транзакций, но это не мешало реализовывать замухрявистую многопользовательскую работу одним только ручным наложением блокировок.
Отсюда и исторически сложившаяся в FP традиция работать "короткими транзакциями", о которых упоминал Sergey Ch (сколь угодно продолжительная работа пользователя с буфером, затем блокировка, тут же проверка, не изменились ли данные другими пользователями, пока шла работа с буфером, и тут же запись и снятие блокировки). Такому поведению соответствует теперешний режим "оптимистических блокировок" в VFP. Он применим практически всегда, за исключением случаев, когда за какой-либо ресурс идет сильная конкуренция. Тогда лучше блокировать, потом редактировать, потом писать и снимать блокировку. Кто первым встал - того и тапки. Это режим "пессимистических блокировок". Но и здесь надо так обустроить, чтобы надолго ресурс не блокировался.
Кстати, а ведь правило, согласно которому надо стараться как можно реже и на минимальное время блокировать ресурсы, оно ведь универсальное. ;-) Т.е. и в "серьезных" серверах негоже раздувать лог транзакций сверх всякой меры ;-)))

Так ведь не покорежил же еще ;-) Блокировка ставится на уровне ОС файл-сервера ;-)
Другое дело, если пользователь запись не только заблокировал, но и писать туда начал уже - и отвалился в это время. Это уже, как правило, приводит к разной тяжести сбоям. Ну а простая блокировка - это еще как бы и ничего. ;-)

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

Файлико можно на уровне ос залочить и по частям.

f_w_pТак никто и не сказал, есть транзакции в FP или нет
Так это зависит от того, какую совокупность мероприятий мы объявим достаточной, чтобы ее можно стало назвать термином "транзакция". ;-)
Если мы будем подразумевать под наличием транзакций в системе только наличие механизма, обеспечивающего целостность некоей логически единой совокупности атомарных операций изменения данных, включая запрет изменения данных другим пользователем или процессом, пока не завершена отработка этой совокупности, и возможность либо целиком сохранить изменения, либо откатить их так же целиком, если что-то пойдет не так, то, безусловно, транзакции в VFP есть. Но механизм транзакций VFP не спасает от порчи таблиц при выключении питания на сервере. И при вылете пользователя посередине незавершенной транзакции не спасает тоже.

nik_xА после этой "каки", на Oracle перешли?Таки перешли ;-)))