ASCRUSВ итоге например, после изменения записи PB генерит примерно такой запрос:
У этого подхода также есть недостатки. Наиболее для меня неприятный - он плохо совместим с желанием чего-то нетривиального. Например, UpdateSQL в дельфе мне пришлось специально отучать от проверки на ROWCOUNT - поскольку как только я захотел менять больше чем одну таблицу, проверка стала возвращать "не то". Другой аспект - зависимости и траффик. Если тянуть на клиента все поля таблицы - получаем большой избыточный траффик. Если нужные - "прозеваем" изменение других полей, из-за чего может возникнуть рассогласование. Вариант наличия гигабайтных блобов тоже заслуживает внимания :)

В целом - я не вижу, что же именно в этом "правильного". Особенно если вспомнить о классическом недостатке - aka "я сделал кучу работы, а теперь ее потеряю".

ASCRUSподход более правильный, чем попытка какой либо блокировки записей при изменении их на клиенте, что изначально противоречит парадигмам разработки клиент-серверных приложений.
Можно поподробнее - формулировку парадигмы и место противоречия?

P.S. Имхо, клиент-серверная парадигма - частный случай общей ООП-парадигмы. Есть объекты (сервер и клиент), которые решают свои задачи и обмениваются сообщениями. Одно из таких сообщений - "дай для просмотра", другое - "дай для изменения". Никаких коллизий не вижу.

funikovyuri softwarer

Чтобы не посылать туда-сюда все поля придуман timestamp
Я согласен с тем, что это лучше нежели "реализованное в PowerBuilder-е".

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

Имхо - этот подход необходимо сочетать с reconsile. Но это уже несколько другой класс решений.

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

Клиент, приехавший завтра на грузовике, с интересом узнает, что его счет не оплачен (и отгрузки не будет) из-за спорной некорректности того, что не нужно в 90% случаев. Видимо, он очень рад и проникается ощущением истинной мудрости гуру от программирования.

Занавес.

Old Nickлогическая блокировка и таких проблем не будет.
Если блокировку все равно надо делать - физическая удобнее. Потому как во-первых удобнее использовать, а во-вторых не будет проблем с теми, кто не знает о существовании логической блокировки.

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

Old Nickинтересно, а в какой ситуации кто-то может не знать о логической блокировке?
О логической блокировке знают только те, кому о ней сказали. Соответственно, можно быть 100% уверенным, что о ней кто-то не знает. Соответственно, надежна она только если доступ к данным перекрыт и абстрагирован - например, appserver-ом. В этом случае проблемой остается только ситуация "нашему специалисту надо поправить в вашей базе..."

Yo!но зато нет проблем с web/wap клиентами у которых на каждый чих новая сесия
Средство героической борьбы с собственноручно созданными трудностями?

Безусловно, в таких условиях строчные блокировки неудачны. Правда, лично мне в таких условиях сразу захотелось бы сделать appserver или еще что-нибудь, что позволит избежать такого идиотизма, как ежесекундные реконнекты.

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

funikovyuri softwarer
в том-то и дело!.....
Я бы сказал несколько иначе. Механизм транзакций - как он реализован - покрывает все мыслимые потребности. По крайней мере, никто пока что не называл мне ситуции, где мне не хватило бы стандартных транзакционных возможностей.

Текущий недостаток БД - неумение держать маленький и эффективный контекст транзакции и переключаться между ними внутри сессии; если угодно - реализации пула на уровне сервера БД. Oracle делает такую попытку (MTS), но, насколько я понимаю, это не то чтобы принципиальный прорыв, поскольку сохраняемый контекст оказывается вовсе не "маленьким и эффективным". Поэтому пул - а значит и все задетые им механизмы - и выезжают из сервера туда, где им вряд ли лучшее место.

funikovyuriтекущая реализация транзакций в РСУБД оптимизирована для какой-то одной стратегии. Обычно это пессимистическое блокирование всех используемых ресурсов в зависимости от уровня изоляции.
Вот это я не совсем понял. Оптимистическая блокировка в транзакциях реализуется ничуть не хуже пессимистической - разве что нет готовой поддержки. Версионники, конечно, могли бы дать здесь инструмент контроля изменений, более удобный чем ручной timestamp.