Количество транзакции после ВЫПОЛНЯЕТСЯ, указывает, что оператор COMMIT или ROLLBACK TRANSACTION отсутствует - SQL-сервер 2005
Я получаю ошибку из приложения как после с SQL-сервером 2005
"Количество транзакции после ВЫПОЛНЯЕТСЯ, указывает, что оператор COMMIT или ROLLBACK TRANSACTION отсутствует. Предыдущее количество = 1, текущее количество = 0 дюймов
Как я могу найти этап, где эта ошибка повышена?
Как я могу найти недостающую транзакцию или хранимую процедуру, где она не фиксируется или быть откатываемым?
3 ответа
Я не думаю, что что-то пропало. Вероятно, это внутренняя хранимая процедура, которая вызывается изнутри транзакции (TRANCOUNT = 1), запускает свою собственную транзакцию (TRANCOUNT = 2), а затем откатывает ее. Ну, это означает откат, но откат влияет на все транзакции, а не только на самую внутреннюю, поэтому процедура портит поток выполнения.
Способ найти место зависит от доступных инструментов / навыков. Лучше использовать SQL Profiler, который показывает все команды, выполняемые приложением на сервере. Найдите самую внешнюю хранимую процедуру и просмотрите ее код в поисках любых других вызовов процедур.
Системная функция @@TRANCOUNT покажет, в скольких транзакциях вы сейчас находитесь. В рамках расследования вставьте утверждения PRINT @@TRANCOUNT или SELECT @@TRANCOUNT в соответствующих местах, чтобы понять, что идет не так.
В «многоуровневой» архитектуре (очень распространенный сценарий) самый глубокий лживый компонент отвечает за предусматривать политики по этому вопросу (может возвращать shared _ ptr < > , как предложено выше, или "вызывающий абонент несет ответственность за удаление этого" или "никогда не удалять это, но вызвать releaseFooObject() при выполнении и отсутствии доступа к нему после "или...), и компонент ближе к пользователю отвечает за соблюдение этой политики.
Двунаправленный информационный поток усложняет описание обязанностей.
ограничивается ли эта проблема только библиотеками DLL или же общие объекты UNIX тоже «причиняются»?
На самом деле это хуже, чем это: вы можете иметь эту проблему так же легко со статически связанными библиотеками. Именно существование границ кода внутри одного контекста выполнения создает возможность неправильного использования или неправильного сообщения о каком-либо объекте.
-121--2145729-Проверьте члена емкости StringBuilder.
Из MSDN :
StringBuilder динамически выделяет больше места при необходимости и соответственно увеличивает емкость. По соображениям производительности StringBuilder может выделять больше памяти, чем требуется. Объем выделенной памяти зависит от реализации.
-121--4244578-это обычно означает, что у вас были вложенные транзакции и был ОТКАТ. Вы не предоставляете никакой информации о запущенном коде, хранимых процедурах, динамическом SQL и т.д. Так что это просто предположение, но я бы сделал поиск «ROLLBACK» и добавить PRINTs или INSERT в YureErrorLogTable после каждого, убедитесь, что содержимое достаточно уникально, чтобы определить, что ROLLBACK был поражен. Другое дело, что вы можете попытаться добавить некоторые блоки TRY - CATCH, где вы включаете PRINTs или INTO YureErrorLogTable в CATCH. Если вы предоставите более подробную информацию о вызываемом коде (вложенные процедуры, вы используете блоки try-catch, динамический sql, linq и т.д.), Я мог бы дать вам более конкретный совет о том, как найти проблему.