Soft54 [игнорируется] 

Решение "в лоб" - с помощью вспомогательного поля "Modifying", в которое записывается ID заблокировавшей запись сессии при открытии записи на редактирование. И далее разрешать редактирование остальных полей только этой сессии.
Но у подобного решения есть и серьёзный концептуальный минус. Юзверь может открыть запись на редактирование и... пойти перекусить. Или комп внезапно перезагрузиться. И запись так и останется заблокированной.

Дабы исключить подобные проблемы лучше всего при открытии документа на редактирование сначала переписать всё его содержимое либо во временные таблицы на сервере, уникальные для каждого пользователя, либо копировать его содержимое в локальный Recordset пользователя. А после завершения редактирования копировать обратно в БД всю совокупность строк.
У такого подхода тоже есть недостаток. Несколько разных пользователей могут взять на редактирование один и тот же документ, по-разному его отредактировать, а сохранится только последняя редакция.

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

Много-много лет назад я делал доклад в клубе RSUG по этой концепции, показывал интерфейс как для реляционных, так и для иерархических данных. Механизмы наследования, версионирования и журнализации. Основной фишкой было два вида времени - учётное (по которому выстраивается последовательность документов) и физическое (для журнализации действий юзверей). Многих тогда доклад впечатлил, часть идей потом использовал 1С в своих наработках.
В целом проект развития не получил - появились более важные и срочные дела. Кроме того, не смотря на красоту концепции, обеспечивалась она заметным снижением быстродействия. Потому мне стало ясно, что для крупных проектов, требующих масштабирования с большим числом юзверей и числом транзакций в минуту эта концепция не очень подходит.