Коллеги, прошу прощение за долгое отсутствие.

Мне подумалось вот что:
Заказчик не требует блокировки редактируемой записи. Только алерт о том, что она редактируется (кем то), и информацию о том, что она была отредактирована кем то, до того, как ты нажал кнопку "сохранить" на данной записи (ну или вышел из строчки грида, когда она была dirty, и она соответственно, полезла сохранятся [заказчик требует, чтобы "было как в excel"]).
Я так понимаю, что это - разные задачи.
Информация о том, что "пока ты телился - запись обновили", решается добавлением в табличку поля timestamp, ну и, соответственно, генерацией ошибки на уровне пишущей хранимки, если таймстампы в твоей копии и в таблице - отличаются. Ну и дополнительный режим этой хранимки "пишем всё равно, пофиг на изменения" (ну, когда затираем редактирование предыдущего пользователя). Тут, правда, наверное, надо будет еще подумать, как обыграть ситуацию, когда запись обновили еще раз, пока пользователь размышлял над ответом "затирать/не затирать".
Вторая задача - это, собственно, показать, что запись сейчас редактируется. Мне наилучшим решением видится, что все пользователи будут слать в некую таблицу ИД записи, ИД клиента, код захватил/отпустил.
Возможно, что туда же эту информацию будут слать триггеры after insert/update/delete, определенные на целевой таблице.
Сборщик мусора на сервере будет удалять из этой таблицы строки, относящиеся к тем, на которых уже нет блокировок (чтобы очередь не росла), возможно, с некоторым лагом.
На эту табличку думаю навесить select на клиенте с привязанной к нему Query Notification (не знаю что за зверь, буду курить). По идее, эта штуковина должна сообщать нам, если выборка на стороне сервера изменится.
Т.е., если нам прилетит сообщение от выборки, что она - поменялась, мы должны перечитать данные из таблицы "блокировок", расставить по другому значки редактирования и выборочно перечитать записи.
Остается проблема со сборкой мусора в случае сбоя клиента.
Частично это можно решить, думаю, так: Если клиент вошел в другую запись, то все его предыдущие блокировки - отменяются. Если клиент залогинился на сервер - то же самое. Если клиент обновил запись - то, видимо, он потерял ее блокировку.
Здесь везде блокировка - это "блокировка", т.е. ничего не блокируется, просто имеется информация о том, что с записью работает пользователь.
Проблема в том, что если клиент потерял коннект абнормально - вот тут ничего не сделаешь. Триггера на logoff у MSSQL вроде нету.

Не устоялось в голове.

Ткните в слабые места, пожалуйста!

Konst_Oneа какой смысл для пользователя видеть некое уведомление о том, что его запись сейчас кем-то редактируется?
В общем, это требование заказчика. Они хаотически кусками обрабатывают один и тот же набор записей с разных машин.
Каждый пользователь, в общем, редактирует свой кусок данных и свою часть записи, но проблема в том, что они могут пересекаться.
Я понимаю, звучит не очень убедительно, но так есть.


carrotikuaggster,

...почему не хранить тогда версии, а окончательное сохранение истинной отдать на усмотрение главного/супервайзера/инспектора пожарной охраны? ... если никто не решится - сохранять последнюю ...
В общем, отредактированные записи всё равно будут сваливаться в "историческую" таблицу триггером. Проблема в том, что пользователь должен увидеть, что при одновременном редактировании он "успел позже".

Изопропилuaggsterсвою часть записи
ТЗ - негодное, это понятно.

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