Идея антиизящная для клиент-серверной архитектуры по своей природе. Длительные блокировки чего-либо для SQL-сервера в принципе противопоказаны - поскольку они будут вносить серъезные помехи работе множества пользователей. Именно поэтому у сервера не предусмотрено никаких средств интерактивного взаимодействия с пользователем, кроме выдачи информационных сообщений (без обратной связи!). Если все будет работать так как ты хочешь, неизбежно возникнет ситуация, когда тупой юзер откроет форму только чтобы посмотреть на данные, а в это время его вызовет руководство, а отттуда он напрямую побежит в буфет, а потом вообще уедет в местную командировку. Все это время други пользователи будут сидеть и ждать у моря погоды. Блокироваться данные должны только на время шевеления ими - чтобы два пользователя не могли одновременно запустить схожую модификацию данных. А смотреть - пусть смотрят хоть толпой.

Вообще-то для решения проблем работы с неактуальными данными существует специальный тип TimeStamp. Конечно, придется повозиться над триггерами, внутри которых должен определяться факт актуальности/неактуальности данных, над которыми производятся операции с откатом выдачей ругательства, если данные уже неактуальны.
Есть и другие приемы, которые можно реализовать собственными методами с использованием вспомогательных "таблиц актуальности". Если пересечения между пользователями происходят достаточно редко, то вполне достаточно выявить факт возникновения неактуальности данных в момент попытки их сохранения, сообщить об этом пользователю и предложить обновить данные на клиенте.
Я, например, использую собственные приемы. Многострочный документ (накладная), может находиться в двух состояниях - "черновик" и "беловик". Пока она находится в состоянии "черновик", она доступна для изменения только одному пользователю - тому, кто ее в это состояние перевел (или создал). В таком состояниии накладная может находиться очень длительное время и на протяжении множества сеансов. Когда на ней ставят метку "беловик", запускаются проводки по регистрам, журнализация и т.д. После этого уже любой пользователь может просматривать ее. И если захочет подправить, снова изменит ее статус на "черновик" - это приведет к уничтожению всех оборотов по регистрам и журнализации уничтожения накладной данным пользователем. А черновик накладной станет доступен только тому, кто эту накладную модифицирует. Когда он откорректирует содержимое накладной, он снова устанвит статус "беловик", накладная снова запустит проводки по регистрам, зажурнализируется ее очередная модификация и она снова станет доступна всем пользователям. При этом остается возможность просмотра истории модификации накладной.
Короче, тут широкое поле для творчества и фантазии.