El recuento de transacciones después de EXECUTE indica un número no coincidente de instrucciones BEGIN y COMMIT. Recuento anterior = 1, recuento actual = 0

Tengo un Insertprocedimiento almacenado que alimentará datos Table1y obtendrá el Column1valor Table1y llamará al segundo procedimiento almacenado que alimentará el Table2.

Pero cuando llamo al segundo procedimiento almacenado como:

Exec USPStoredProcName

Obtuve el siguiente error:

El recuento de transacciones después de EXECUTE indica un número no coincidente de instrucciones BEGIN y COMMIT. Recuento anterior = 1, recuento actual = 0.

He leído las respuestas en otras preguntas similares y no puedo encontrar dónde se está estropeando exactamente el recuento de confirmaciones.

Si tiene un bloque TRY / CATCH, la causa probable es que esté detectando una excepción de cancelación de transacción y continúe. En el bloque CATCH siempre debe marcar XACT_STATE()y manejar las transacciones apropiadas abortadas y no compatibles (condenadas). Si la persona que llama inicia una transacción y la llamada llega, digamos, a un punto muerto (que canceló la transacción), ¿cómo va a comunicar la persona que llama a la persona que llama que la transacción fue cancelada y que no debería continuar con el 'negocio como de costumbre'? La única forma viable es volver a generar una excepción, lo que obliga a la persona que llama a manejar la situación. Si traga silenciosamente una transacción abortada y la persona que llama continúa asumiendo que todavía está en la transacción original, solo el caos puede asegurarse (y el error que obtiene es la forma en que el motor intenta protegerse).

Le recomiendo que revise el manejo de excepciones y las transacciones anidadas, que muestra un patrón que se puede usar con transacciones anidadas y excepciones:

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

Yo tuve este problema también. Para mí, la razón era que estaba haciendo

return
commit

en vez de

commit
return   

en un procedimiento almacenado.

Esto sucede normalmente cuando se inicia la transacción y no se confirma o no se deshace.

En caso de que el error aparezca en su procedimiento almacenado, esto puede bloquear las tablas de la base de datos porque la transacción no se completa debido a algunos errores de tiempo de ejecución en ausencia de manejo de excepciones. Puede usar el manejo de excepciones como se muestra a continuación. SET XACT_ABORT

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

Fuente

Tenga en cuenta que si utiliza transacciones anidadas, una operación ROLLBACK revierte todas las transacciones anidadas, incluida la más externa.

Esto podría, con el uso en combinación con TRY / CATCH, dar como resultado el error que describió. Vea más aquí .

Esto también puede ocurrir si su procedimiento almacenado encuentra un error de compilación después de abrir una transacción (por ejemplo, tabla no encontrada, nombre de columna no válido).

Descubrí que tenía que usar 2 procedimientos almacenados, uno de "trabajador" y uno de envoltura con try / catch, ambos con una lógica similar a la descrita por Remus Rusanu. La captura de trabajador se usa para manejar los errores "normales" y la captura de contenedor para manejar los errores de falla de compilación.

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

Errores que no se ven afectados por una construcción TRY… CATCH

Los siguientes tipos de errores no son manejados por un bloque CATCH cuando ocurren en el mismo nivel de ejecución que la construcción TRY… CATCH:

• Compile errores, como errores de sintaxis , que impiden la ejecución de un lote.
• Errores que ocurren durante la recompilación a nivel de instrucción, como errores de resolución de nombres de objetos que ocurren después de la compilación debido a una resolución de nombres diferida.

Esperemos que esto ayude a alguien más a ahorrar unas horas de depuración ...

En mi caso, el error fue causado por un RETURNarchivo BEGIN TRANSACTION. Entonces tuve algo como esto:

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

y debe ser:

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

Para mí, después de una depuración extensa, la solución fue un simple tiro faltante; declaración en la captura después de la reversión. Sin él, este feo mensaje de error es con lo que terminas.

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

Tuve el mismo mensaje de error, mi error fue que tenía un punto y coma al final de la línea COMMIT TRANSACTION

Encontré este error una vez después de omitir esta declaración de mi transacción.

COMMIT TRANSACTION [MyTransactionName]

En mi opinión, la respuesta aceptada es en la mayoría de los casos una exageración.

La causa del error a menudo es la falta de coincidencia de BEGIN y COMMIT como se indica claramente en el error. Esto significa usar:

Begin
  Begin
    -- your query here
  End
commit

en vez de

Begin Transaction
  Begin
    -- your query here
  End
commit

¡omitir Transacción después de Comenzar causa este error!

Asegúrese de no tener varias transacciones en el mismo procedimiento / consulta, de las cuales una o más quedan sin comprometer.

En mi caso, accidentalmente tuve una declaración BEGIN TRAN en la consulta

Esto también puede depender de la forma en que invoca el SP desde su código C #. Si el SP devuelve algún valor de tipo de tabla, invoque el SP con ExecuteStoreQuery, y si el SP no devuelve ningún valor, invoque el SP con ExecuteStoreCommand

Evitar el uso de

RETURN

declaración cuando estás usando

BEGIN TRY
    ... 
END TRY

BEGIN CATCH
    ...
END CATCH

y

BEGIN, COMMIT & ROLLBACK

declaraciones en procedimientos almacenados SQL

Si tiene una estructura de código de algo como:

SELECT 151
RETURN -151

Entonces usa:

SELECT 151
ROLLBACK
RETURN -151