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

Intenta interpretar el código bien previamente a usarlo a tu trabajo si ttienes algo que aportar puedes compartirlo con nosotros.

Solución:

Si tiene un bloque TRY/CATCH, la causa probable es que está detectando una excepción de cancelación de transacción y continúa. En el bloque CATCH siempre debe marcar el XACT_STATE() y manejar transacciones abortadas y no comprometidas (condenadas) apropiadas. Si la persona que llama inicia una transacción y la persona que recibe la llamada llega, por ejemplo, a un interbloqueo (que abortó la transacción), ¿cómo le comunicará la persona que llama a la persona que llama que la transacción fue abortada y que no debe continuar con “negocios como de costumbre”? La única forma factible es volver a generar una excepción, obligando 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 garantizar (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 muestran 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

También tuve este problema. Para mí, la razón fue que estaba haciendo

return
commit

en vez de

commit
return   

en un procedimiento almacenado.

Esto normalmente ocurre cuando se inicia la transacción y no se confirma o no se revierte.

En caso de que el error se presente 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 del manejo de excepciones. Puede usar el manejo de excepciones como se muestra a continuación. ESTABLECER 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

Tienes la posibilidad compartir este post si te fue de ayuda.

---

---

Utiliza Nuestro Buscador