Не обязательно. Просто два пользователя одновременно нажали одну и ту же кнопку.
Твой план искать незавершённую транзакцию в данном случае бесполезен и только
тратит зря время.


В сообщении 22397414 я написал, что я проделал и почему сделал вывод, что транзакция именно в моем приложении. Пока не будет доказано обратное, считаю за аксиому, что изменения, послужившие причиной блокировки, сделаны в моем приложении (как вариант, в функции из dll, вызванной из моего приложения.


Давайте я немного расскажу про выполняемый код. Это все -- проведение документа. В процессе проведения выполняются всякие содержательные проверки, расчеты и т.п. На каждом этапе что-то изменяется в таблице: пересчитывается сумма, обновляется дата, меняются флажки, обозначающие какое-то изменение состояния и т.п. Цепочка действий может быть ветвистой, некоторые этапы могу выглядеть по-разному, некоторые -- вообще отсутствовать, но в любом случае -- это последовательность изменений. И каждое из них, по логике, выполняется в короткой транзакции, которая явно стартует и явно завершается. Если на каком-то этапе ХП вернула ошибку, то есть этап выполнился некорректно, соответствующая транзакция откатывается и на этом дальнейшее проведение прекращается. Тот UPDATE, на котором я ловлю конфликт, всего лишь выставляет битовый признак, означающий что документ распечатан. Я не могу заменить UPDATE на INSERT: мне надо в конкретной записи в конкретном поле значение поменять. Если я выполню этот UPDATE в рамках предыдущей транзакции, а она откатится, то ничего страшного: если бы она завершилась по ROLLBACK вовремя, то мой запрос UPDATE вообще не выполнялся бы.

Как-то так.

Можешь и должен. Выкинуть нафиг этот битовый признак, вместо него добавлять
запись "документ распечатан" в историю операций над документом.

Повторять так для каждой операции, которая наткнётся на конфликт. Другого пути -
нет.

Вот здесь у меня непонятки.
Допустим, я найду место, куда можно добавить информацию, что документ распечатан.
Допустим даже, что я найду в своем приложении все места, где используется поле из этой таблицы, и заменю на вызов записи из другой таблицы.
Но мое приложение -- это часть системы. И мне никто не позволит изменять все систему только потому, что в одном приложении где-то допустили ляп и в одном случае из десяти тысяч возникает lock coflict при апдейте. Так что это годится как временная мера, но не как окончательное решение. Устранять же проблему придется по-любому. И нормальным способом.

Игрушка "Сапер" была доработана, но после доработки иногда стал возникать глюк.
Разработчик не смог найти причину появления этого глюка, поэтому решил переписать kernel32.dll :)
Не знаю, как обстоит дело у Microsoft, но у нас мне никто не позволит переделывать структуру БД только потому, что в одном из приложений допущен ляп, который я не могу локализовать и устранить.


Не-а... данное приложение как раз и создано для создания и проведения документа. Причем один документ создается и проводится одним экземпляром приложения. Все остальные могут документ читать, но не изменять.

* * *
Сразу расставим палочки над t
У меня есть возможность изменить код клиентского приложения, чтобы:
1. Найти, где у меня незавершенная транзакция, и завершить ее до выполнения UPDATE (оптимальный вариант).
2. Определить, что есть незавершенная программа и как-то обеспечить корректное выполнение UPDATE (принудительно закрыть предыдущую транзакцию; не стартовать новую транзакцию, а внести изменения в рамках уже имеющейся и.т.п.).

Поскольку только один клиент вносит изменения в документ, то случайность обусловлена не тем, что два человека одновременно решили внести правки, а проколом в работе с транзакциями. Что-то где-то поменяли в коде приложения, после чего стала иногда возникать такая вот ошибка. Условия возникновения ошибки также неизвестны. Если я смогу осмысленно воспроизвести ошибку, я тогда и с проблемой разберусь.

Вот я и повторяю постоянно: где в какой момент что запросить у сервера либо у dbExpress, чтобы локализовать ошибку или хотя бы сократить пространство поиска.


3. Найти все места в приложении, где при данной операции изменяется данная
таблица и свести их в один UPDATE чтобы он производился один раз за операцию.
4. Начать использовать явное управление транзакциями в данном приложении чтобы в
нём вообще осталась всего одна транзакция на всю проводку документа.


Дочка спрашивает у мамы:
- Как правильно пишется "флякончик" или "флюкончик"?
- Напиши "пизирек", - отвечает мама.
:)

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

Причины проблемы, более-менее, очевидны.
В качестве способа устранения предложен вариант в стиле лечения головной боли посредством гильотины.
А вот про локализацию что-то особо не заметил. Или вы про трассировку? Тогда я уже объяснил, почему это неприменимо. Не знаете другого способа как определить запрос или несколько потенциальных запросов, которые могут вызвать блокировку? Так и скажите, буду сам думать.


Вот этого я не понял. Это вопрос или утверждение? Почему UPDATE-ы запрещены? Как изменять значения полей записи?


На вопрос "Как выявить запрос, приводящий к блокировке (или незавершенную транзакцию), мне рекомендуют:
1. Писать программы хорошо, тогда таких проблем не будет.
2. Переписать систему "правильно"
А упорот, конечно же, "поциент"
Кстати, на другом форуме могли бы посоветовать еще и СУБД заменить на "нормальную" :)


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


А почему тогда логирование UPDATE на триггер не повесить? База большая, изменяться таблица может много откуда: запросами UPDATE, хранимыми процедурами, скриптами. Все места внесения изменений можем и не найти. Да и не позволит мне никто кардинально менять метаданные. Все изменения в метаданные должны вноситься только официальными обновлениями. Обосновать разработку такого обновления я не смогу.

Но, опять же скажу, 95% за то, что есть косячок в клиентском приложении, и его надо бы найти А для этого хотя бы определить запрос, который заблокировал запись. Или несколько запросов, которые могли это сделать. И от этого уже плясать.
Надо было задавать вопрос на форуме программистов на Delphi :)

Вот такой запрос может мне помочь?


где NNN -- ID транзакции, содержащей блокирующий запрос. Каков смысл поля MON$STATE, могу ли я в поисках интересующего меня запроса отфильтровывать записи по значению этого поля, так как они точно не при делах?

[+]

Вы предполагаете, а я знаю, что этого нет. Точнее, что это не планировалось, так что если есть такое, то чей-то косяк.
Но тогда мы нарывались бы на lock conflict в разных местах. А мы нарываемся в о дном и том же запросе UPDATE

ну смотри - допустим, в софте произошла ошибка по блокировке UPDATE. Ты тут же бросаешься смотреть в mon$, кто там и что. Но пока ты делал снимок mon$, конкурирующая транзакция завершилась. Всё, концов не найти.
А трассировка дедлоков по статье, которую я привел, запускается НАДОЛГО. Именно для того чтобы найти только deadlock. И тогда что-то еще можно найти.
Так что, других вариантов нет.
Про трассировку я и не возражал. Только тут такой нюанс, что клиентские компьютеры и сервера принадлежать не мне, а заказчику. А он может и не позволить изменять настройку серверов или запускать лишнее программное обеспечение на клиентских компьютерах. Поэтому приходиться крутиться.

По крайней мере, запрос к mon$transactions блокируюущую транзакцию поймал. Будем надеяться, что и запрос к mon$statements не оплошает.
Так как насчет mon$statements.mon$state? Могу ли я по значению этого поля определить те записи, которые заведомо не могут блокировать таблицу?