Я то как раз и хочу просмотреть только тот десяток ХП, которые выполняюстя в блокирующей транзакции. А мне дают советы как увеличить это количество.

GJИ что я тогда буду искать? Одновременную работу нескольких транзакций что ли?

Да, именно это я и сказал. Кажется, даже два раза.
[/quot]
Сделал у себя на локальной БД, как ты сказал, прошел, одновременно работающих транз0акций не обнаружено. Дальше что?
И не получится как в том анекдоте... "Жаль, что все куры сдохли, а то у меня еще столько идей"


Потому, что они порождают блокировки и безвозвратные потери первички.
Никак не изменять. Делать только инсерты. Изменять можно потом, джобом или монопольно при пересменке.[/quot]
За четверть века работы с базами данных впервые встречаю утверждение о недопустимости применения запроса UPDATE при работе в многопользовательском режиме :)
Нет, если вы рассматриваете вариант когда в некоей абстрактной БД сотня обезьян одновременно занимается изменением данных посредством низкоуровневых запросов, то, скорее всего, вы правы.
Но я работаю с вполне конкретной системой, при проектировании которой изначально учитывалась одновременная работа многих пользователей. И нигде больше одновременно со мной никто в этой записи значения полей не меняет. Так что глупо как-то выбрасывать существующую систему и делать новую, по вашей идеологии, когда речь идет всего лишь о поиске ошибки.


Вы, похоже, совсем не читаете, что я пишу. Допустим, сделал я такой супер-мега-скрипт, который меняет кучу метаданных в БД. И что? Могу положить его на полочку и любоваться, потому что воспользоваться им не смогу. Ваш совет хорош в случае, если я -- хозяин БД. Тогда, да. Запустил IBExpert, быстренько поправил несколько сотен ХП, дописал еще несколько сотен новых... и жди, когда яблочко свалится тебе в руки.
А так... я разработку уже закончил. Философские споры -- штука бесконечная. Как только я понял, что ничего содержательного больше не будет, то сразу вставил в приложение дополнительное логирование. Теперь буду ждать, когда ошибка возникнет снова, а потм смотреть ХП, попавшие в логи, и искать место ошибки.

Не может репликатор изменить. Правки в документ могут вноситься только на одной БД. Если нужно править на другой БД, требуется передача прав. Более того, даже на одной БД если кто-то редактирует документ, остальн6ые могут только читать, но не править. Если, конечно, триггеры не отключать :)
Система изначально спроектирована так, чтобы можно было без опаски пользоваться изменением таблиц, а не загонять все изменения в некий черновик, из которого потом по ночам в монопольном режиме выполнять синхронизацию данных.


Изменяется сумма чека при добавлении товара, изменении количества товара по строке, при изменении цены товара (например, при использовании дисконтной карты). Меняется сумма оплат по чеку (например, частичная оплата банковской картой или бонусами), меняется состояние документа, меняются различные признаки. Так проблемный апдейт фиксирует тот фат, что чек был фискализирован. Если фискальный регистратор вдруг забарахлит, когда чек уже проведен. то мы потом увидим, что отметки о фискализации нет, и попробуем его фискализировать еще раз.


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


Значит надо проверять какой из высказанных выше постулатов ложен:
1) Конкурирующая транзакция находится в твоём приложении. 22397414
2) Твоё приложение всегда запущено в одном экземпляре. 22397656

Оба постулата истинны. А причина в том, что я не могу у себя на локально БД гарантировать прохождение в коде по тому же пути с теми же данными. Говорю же, что проблема возникает только у одного заказчика и очень редко.
Если бы я мог у себя воспроизвести эту проблему, я бы ее уже устранил.

Пока это проделывается только в одном документе только одной транзакцией -
сабжевой ошибки быть не может.

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



Значит таки придётся пройти всё дерево триггеров, активируемых проблемным
запросом, для выявления "какая же таблица может быть изменена за пределами
своего документа".

PS: И анализ надо проводить именно на метаданных данного клиента, ибо там могут быть незаявленные изменения.
Пока буду исходить из предположения, что в рамках блокирующей транзакции вносятся изменения ту же самую таблицу, которую пытается изменить запрос UPDATE. Для этого хочу получить список всех запросов, которые выполнялись в блокирующей транзакции. Если там есть такие, то буду искать, откуда они вызываются, и как могло получится, что транзакция оказалась незавершенной. Если нет, тогда уже перейдем к триггерам. Слишком уж там сложно все, потону в анализе.

Это ты уже проверил трассировкой. Транзакция одна.

Я проверил на локальной базе. Одна. А у заказчика получается две. Иногда. При каких условиях, хз.

Вы с Винвордом что ли обычно рнаботаете? Типа, сначала набрали доркумент, потом сохранили :)
Я говорю не про кассовы чек, который вылезает из кассового аппарата. В системе есть понятие "документ "Кассовый чек"". Реализовано это как совокупность записей из разных таблиц. Его составление и проведение -- это последовательность шагов, которые должны быть отражены в базе данных, так как в на эту информацию завязана работа других алгоритмов. Пробитие чека на кассе и фиксация результата этой операции -- один из завершающих шагов.
Во избежание блокировок в систему заложен специальный механизм, препятствующий одновременному изменению документа из разных мест. Если вы знаете только один способ -- никаких UPDATE, только INSERT, а потом все разом внесем -- то это ваше личное дело.


Это не великодушие, а обычная вежливость.


т т.п.

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

* * *

Тоже бегло просмотрел (только упор больше делал на исходники, а не на хелп). И пришел, в основном, к таким же выводм. Была надежда, что я что-о недопонял, и есть шарящие люди, которые меня поправят. Ну, да ладно.


Когда приложение разрабатывали, старались использовать короткие транзакции. То есть старт и завершение транзакции в одной подпрограмме. Но потом код разросся (в том числе и те самые подпрограммы с транзакцией), стал более ветвистым... и где-то при каких-то условиях стал возникать ляп: то ли вообще COMMIT пропустили, то ли выполнили его с другим TTransactionDesc. Перерывать все -- это реально умереть и не встать. Сейчас вот вставил в приложение сброс в лог запросов из mon$statements, если на моменет выполнения проблемного UPDATE есть другие активные транзакции. Жаль, что там только перечень запросов, но нет порядка их выполнения (иди все же есть?). Но все же это поможет сократить пространство поиска возможного места ляпа.

[+]

У меня сложилось впечатление, что разработчики dbExpress держали в голове веб-приложения: подключились, стартовали транзакцию, открыли запрос, пробежались, создавая html-страничку, завершили работу.

Где?
Диалог вкратце:
-- Причина ошибки в том, что запись была изменена в другой транзакции.
-- Спасибо, я знаю.
-- Блокирует другое приложение.
-- Провери вот так и так, получается, что приложение то же самое.
-- Переделай все запросы апдейт на INSERT с последующим обновлением в монопольном режиме.
-- (тут я просто в афиге и не знаю, что ответить: посоветуйте Микрософту отказаться от окон, так как в них сплошные глюки).
-- Выполните трассировку.
-- Ошибка только у заказчика, а он не позволит ничего запускать; у меня ошибка не воспроизводится.
-- Проверьте все ХП.
-- Их несколько тысяч. Можно я посмотрю только те ХП, которые выполняются в блокирующей транзакции?
-- ... и дальше по кругу.

Пардон, если кого-то пропустил :)


Что в данном контексте означает слово "трассировать"? Запускать упомянутую выше программы трассировки? Если да, то на какой машине (я уже знаю все подводные камни :))? На компах заказчика заказчик не позволит, на моем -- ошибка не ловится.


Почему все?! Я разве не говорил, что ошибка возникает только в одном месте. Именно этот один запрос UPDATE я и собираюсь мониторить.