Кількість транзакцій після EXECUTE вказує на невідповідність кількості операторів BEGIN та COMMIT. Попередній рахунок = 1, поточний рахунок = 0

У мене є Insertзбережена процедура, яка подаватиме дані Table1та отримуватиме Column1значення, Table1а також викликатиме другу збережену процедуру, яка буде подавати таблицю2.

Але коли я називаю другу збережену процедуру як:

Exec USPStoredProcName

Я отримую таку помилку:

Кількість транзакцій після EXECUTE вказує на невідповідність кількості операторів BEGIN та COMMIT. Попередній рахунок = 1, поточний рахунок = 0.

Я прочитав відповіді в інших таких запитаннях і не можу знайти, де саме кількість рахунків стає заплутаною.

Якщо у вас є блок TRY / CATCH, то, швидше за все, ви ловите виняток щодо переривання транзакції та продовжуєте. У блоці CATCH ви завжди повинні перевіряти XACT_STATE()та обробляти відповідні перервані та несумісні (приречені) транзакції. Якщо ваш абонент розпочинає транзакцію, а calee потрапляє, скажімо, у глухий кут (що призвело до припинення транзакції), як викликана особа повідомляє абоненту про те, що транзакція була перервана, і вона не повинна продовжувати роботу як зазвичай? Єдиним можливим способом є повторне виняток, що змушує абонента вирішити ситуацію. Якщо ви мовчки проковтнете перервану транзакцію, а абонент продовжує припускати, що вона все ще знаходиться в початковій транзакції, може забезпечити лише погром (і помилка, яку ви отримуєте, полягає в тому, як двигун намагається захистити себе).

Я рекомендую вам перейти до обробки винятків та вкладених транзакцій, де показано шаблон, який можна використовувати з вкладеними транзакціями та винятками:

create procedure [usp_my_procedure_name]
as
begin
    set nocount on;
    declare @trancount int;
    set @trancount = @@trancount;
    begin try
        if @trancount = 0
            begin transaction
        else
            save transaction usp_my_procedure_name;

        -- Do the actual work here

lbexit:
        if @trancount = 0
            commit;
    end try
    begin catch
        declare @error int, @message varchar(4000), @xstate int;
        select @error = ERROR_NUMBER(), @message = ERROR_MESSAGE(), @xstate = XACT_STATE();
        if @xstate = -1
            rollback;
        if @xstate = 1 and @trancount = 0
            rollback
        if @xstate = 1 and @trancount > 0
            rollback transaction usp_my_procedure_name;

        raiserror ('usp_my_procedure_name: %d: %s', 16, 1, @error, @message) ;
    end catch
end
go

У мене теж була ця проблема. Для мене причиною було те, що я робив

return
commit

замість

commit
return   

за одну збережену процедуру.

Зазвичай це трапляється, коли транзакція запущена, або вона не фіксується, або не відміняється.

Якщо у вашій збереженій процедурі виникає помилка, це може заблокувати таблиці бази даних, оскільки транзакція не завершена через деякі помилки виконання під час відсутності обробки винятків. Ви можете використовувати обробку винятків, як показано нижче. ВСТАНОВИТИ XACT_ABORT

SET XACT_ABORT ON
SET NoCount ON
Begin Try 
     BEGIN TRANSACTION 
        //Insert ,update queries    
     COMMIT
End Try 
Begin Catch 
     ROLLBACK
End Catch

Джерело

Майте на увазі, що якщо ви використовуєте вкладені транзакції, операція ROLLBACK відкочує всі вкладені транзакції, включаючи саму зовнішню.

Це може при використанні у поєднанні з TRY / CATCH призвести до помилки, яку ви описали. Дивіться більше тут .

Це також може статися, якщо ваша збережена процедура зіштовхується з помилкою компіляції після відкриття транзакції (наприклад, таблиця не знайдена, неправильне ім'я стовпця).

Я виявив, що мені довелося використовувати 2 збережені процедури, "робочу", та обгортку, із спробою / ловом, обидві з логікою, подібною до описаної Ремусом Русану. Робочий уловник використовується для обробки "звичайних" помилок, а обгортковий обробник - для обробки помилок компіляції.

https://msdn.microsoft.com/en-us/library/ms175976.aspx

Помилки, на які не впливає конструкція Спробуй… Улов

Наступні типи помилок не обробляються блоком CATCH, коли вони трапляються на тому ж рівні виконання , що і конструкція TRY… CATCH:

• Компілюйте помилки, такі як синтаксичні помилки , які перешкоджають запуску пакета.
• Помилки, які виникають під час перекомпіляції на рівні виписки, наприклад, помилки роздільної здатності імен об’єктів, що виникають після компіляції через відкладене роздільне ім’я.

Сподіваємось, це допоможе комусь іншому заощадити кілька годин налагодження ...

У моєму випадку помилка була спричинена RETURNвсередині BEGIN TRANSACTION. Тож у мене було щось подібне:

Begin Transaction
 If (@something = 'foo')
 Begin
     --- do some stuff
     Return
 End
commit

і це повинно бути:

Begin Transaction
 If (@something = 'foo')
 Begin
     --- do some stuff
     Rollback Transaction ----- THIS WAS MISSING
     Return
 End
commit

Для мене після великої налагодження виправлення було простим відсутнім кидком; заяву в улові після відкоту. Без нього це потворне повідомлення про помилку - це те, з чим ви закінчуєтесь.

begin catch
    if @@trancount > 0 rollback transaction;
    throw; --allows capture of useful info when an exception happens within the transaction
end catch

У мене було таке саме повідомлення про помилку, моя помилка полягала в тому, що я мав крапку з комою в кінці РЕАЛІЗАЦІЇ ОПЕРАЦІЇ

Я зіткнувся з цією помилкою один раз, пропустивши цю заяву з моєї транзакції.

COMMIT TRANSACTION [MyTransactionName]

На мій погляд, прийнята відповідь у більшості випадків є надмірною.

Причиною помилки часто є невідповідність BEGIN і COMMIT, як чітко зазначено в помилці. Це означає використання:

Begin
  Begin
    -- your query here
  End
commit

замість

Begin Transaction
  Begin
    -- your query here
  End
commit

пропуск Transaction after Begin спричиняє цю помилку!

Переконайтеся, що у вас немає декількох транзакцій в одній і тій же процедурі / запиті, з яких одна або декілька залишаються нерозв’язаними.

У моєму випадку у запиті випадково з’явилося твердження BEGIN TRAN

Це також може залежати від способу виклику SP із коду C #. Якщо SP повертає якесь значення типу таблиці, тоді викликайте SP за допомогою ExecuteStoreQuery, а якщо SP не повертає жодного значення, викличте SP за допомогою ExecuteStoreCommand

Уникайте використання

RETURN

, коли ви використовуєте

BEGIN TRY
    ... 
END TRY

BEGIN CATCH
    ...
END CATCH

і

BEGIN, COMMIT & ROLLBACK

оператори в збережених процедурах SQL

Якщо у вас є кодова структура приблизно такого:

SELECT 151
RETURN -151

Потім використовуйте:

SELECT 151
ROLLBACK
RETURN -151