Il conteggio delle transazioni dopo EXECUTE indica un numero non corrispondente di istruzioni BEGIN e COMMIT. Conteggio precedente = 1, conteggio corrente = 0

Ho una Insertprocedura memorizzata che alimenterà i dati Table1e otterrà il Column1valore da Table1e chiamerà la seconda procedura memorizzata che alimenterà il Table2.

Ma quando chiamo La seconda procedura memorizzata come:

Exec USPStoredProcName

Ottengo il seguente errore:

Il conteggio delle transazioni dopo EXECUTE indica un numero non corrispondente di istruzioni BEGIN e COMMIT. Conteggio precedente = 1, conteggio corrente = 0.

Ho letto le risposte in altre domande simili e non sono in grado di trovare dove esattamente il conteggio dei commit viene incasinato.

Se hai un blocco TRY / CATCH, la causa probabile è che stai rilevando un'eccezione di interruzione della transazione e continui. Nel blocco CATCH devi sempre controllare XACT_STATE()e gestire le transazioni abortite e non modificabili (condannate) appropriate. Se il chiamante avvia una transazione e il calee colpisce, ad esempio, un deadlock (che ha interrotto la transazione), come farà il chiamato a comunicare al chiamante che la transazione è stata interrotta e non dovrebbe continuare con "business as usual"? L'unico modo possibile è rilanciare un'eccezione, costringendo il chiamante a gestire la situazione. Se ingoi silenziosamente una transazione interrotta e il chiamante continua a supporre che sia ancora nella transazione originale, solo il caos può garantire (e l'errore che ottieni è il modo in cui il motore cerca di proteggersi).

Ti consiglio di esaminare la gestione delle eccezioni e le transazioni nidificate che mostra un modello che può essere utilizzato con transazioni ed eccezioni nidificate:

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

Anch'io ho avuto questo problema. Per me, il motivo era che stavo facendo

return
commit

invece di

commit
return   

in una procedura memorizzata.

Ciò accade normalmente quando la transazione viene avviata e non viene eseguito il commit o non viene eseguito il rollback.

Nel caso in cui l'errore si verifichi nella procedura memorizzata, questo può bloccare le tabelle del database perché la transazione non è stata completata a causa di alcuni errori di runtime in assenza di gestione delle eccezioni È possibile utilizzare la gestione delle eccezioni come di seguito. 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

fonte

Tenere presente che se si utilizzano transazioni nidificate, un'operazione ROLLBACK ripristina tutte le transazioni nidificate, inclusa quella più esterna.

Questo potrebbe, con l'utilizzo in combinazione con TRY / CATCH, causare l'errore descritto. Vedi di più qui .

Ciò può verificarsi anche se la procedura memorizzata incontra un errore di compilazione dopo l'apertura di una transazione (ad es. Tabella non trovata, nome di colonna non valido).

Ho scoperto di dover utilizzare 2 stored procedure una "worker" e una wrapper con try / catch entrambe con logica simile a quella delineata da Remus Rusanu. Il catch worker viene utilizzato per gestire gli errori "normali" e il catch wrapper per gestire gli errori di errore di compilazione.

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

Errori non influenzati da un costrutto TRY… CATCH

I seguenti tipi di errori non vengono gestiti da un blocco CATCH quando si verificano allo stesso livello di esecuzione del costrutto TRY… CATCH:

• Errori di compilazione, come errori di sintassi , che impediscono l'esecuzione di un batch.
• Errori che si verificano durante la ricompilazione a livello di istruzione, ad esempio errori di risoluzione dei nomi degli oggetti che si verificano dopo la compilazione a causa della risoluzione dei nomi differita.

Si spera che questo aiuti qualcun altro a risparmiare qualche ora di debug ...

Nel mio caso, l'errore è stato causato da un RETURNall'interno del BEGIN TRANSACTION. Quindi ho avuto qualcosa del genere:

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

e deve essere:

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

Per me, dopo un lungo debug, la correzione era un semplice lancio mancante; dichiarazione nella cattura dopo il rollback. Senza di esso questo brutto messaggio di errore è ciò che ti ritroverai con.

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

Ho ricevuto lo stesso messaggio di errore, il mio errore era che avevo un punto e virgola alla fine della riga COMMIT TRANSACTION

Ho riscontrato questo errore una volta dopo aver omesso questa istruzione dalla mia transazione.

COMMIT TRANSACTION [MyTransactionName]

A mio parere, la risposta accettata è nella maggior parte dei casi eccessiva.

La causa dell'errore è spesso la mancata corrispondenza tra BEGIN e COMMIT, come chiaramente indicato dall'errore. Ciò significa utilizzare:

Begin
  Begin
    -- your query here
  End
commit

invece di

Begin Transaction
  Begin
    -- your query here
  End
commit

omettere Transaction dopo Begin causa questo errore!

Assicurati di non avere più transazioni nella stessa procedura / query di cui una o più vengono lasciate non vincolate.

Nel mio caso, ho ricevuto accidentalmente un'istruzione BEGIN TRAN nella query

Ciò può dipendere anche dal modo in cui si richiama l'SP dal codice C #. Se l'SP restituisce un valore di tipo tabella, richiamare l'SP con ExecuteStoreQuery e, se l'SP non restituisce alcun valore, richiamare l'SP con ExecuteStoreCommand

Evitare di utilizzare

RETURN

dichiarazione quando si utilizza

BEGIN TRY
    ... 
END TRY

BEGIN CATCH
    ...
END CATCH

e

BEGIN, COMMIT & ROLLBACK

istruzioni nelle procedure memorizzate SQL

Se hai una struttura del codice simile a:

SELECT 151
RETURN -151

Quindi usa:

SELECT 151
ROLLBACK
RETURN -151