Le nombre de transactions après EXECUTE indique un nombre incompatible d'instructions BEGIN et COMMIT. Comptage précédent = 1, nombre actuel = 0

J'ai une Insertprocédure stockée qui alimentera les données Table1et en obtiendra la Column1valeur Table1et appellera la deuxième procédure stockée qui alimentera le Table2.

Mais quand j'appelle la deuxième procédure stockée comme suit:

Exec USPStoredProcName

J'obtiens l'erreur suivante:

Le nombre de transactions après EXECUTE indique un nombre incompatible d'instructions BEGIN et COMMIT. Compte précédent = 1, nombre actuel = 0.

J'ai lu les réponses à d'autres questions de ce type et je ne suis pas en mesure de trouver exactement où le nombre de validations est perturbé.

Si vous avez un bloc TRY / CATCH, la cause probable est que vous détectez une exception d'abandon de transaction et que vous continuez. Dans le bloc CATCH, vous devez toujours vérifier XACT_STATE()et gérer les transactions avortées et non validables (condamnées) appropriées. Si votre appelant commence une transaction et que l'appelant rencontre, par exemple, une impasse (qui a annulé la transaction), comment l'appelé va-t-il communiquer à l'appelant que la transaction a été annulée et qu'elle ne devrait pas continuer avec le «statu quo»? Le seul moyen possible est de relancer une exception, forçant l'appelant à gérer la situation. Si vous avalez silencieusement une transaction annulée et que l'appelant continue de supposer qu'il est toujours dans la transaction d'origine, seul le chaos peut garantir (et l'erreur que vous obtenez est la façon dont le moteur essaie de se protéger).

Je vous recommande de passer en revue la gestion des exceptions et les transactions imbriquées qui montre un modèle qui peut être utilisé avec des transactions imbriquées et des exceptions:

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

J'ai eu ce problème également. Pour moi, la raison était que je faisais

return
commit

au lieu de

commit
return   

dans une procédure stockée.

Cela se produit normalement lorsque la transaction est lancée et qu'elle n'est pas validée ou qu'elle n'est pas annulée.

Si l'erreur survient dans votre procédure stockée, cela peut verrouiller les tables de la base de données car la transaction n'est pas terminée en raison d'erreurs d'exécution en l'absence de gestion des exceptions. Vous pouvez utiliser la gestion des exceptions comme ci-dessous. 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

La source

Sachez que si vous utilisez des transactions imbriquées, une opération ROLLBACK annule toutes les transactions imbriquées, y compris la plus externe.

Cela peut, avec une utilisation en combinaison avec TRY / CATCH, entraîner l'erreur que vous avez décrite. En savoir plus ici .

Cela peut également se produire si votre procédure stockée rencontre un échec de compilation après l'ouverture d'une transaction (par exemple, table non trouvée, nom de colonne non valide).

J'ai trouvé que je devais utiliser 2 procédures stockées, une "worker" et une wrapper avec try / catch toutes les deux avec une logique similaire à celle décrite par Remus Rusanu. Le catch worker est utilisé pour gérer les échecs "normaux" et le catch du wrapper pour gérer les erreurs d'échec de compilation.

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

Erreurs non affectées par une construction TRY… CATCH

Les types d'erreurs suivants ne sont pas traités par un bloc CATCH lorsqu'ils se produisent au même niveau d'exécution que la construction TRY… CATCH:

• Compilez les erreurs, telles que les erreurs de syntaxe , qui empêchent l'exécution d'un lot.
• Erreurs qui se produisent pendant la recompilation au niveau de l'instruction, telles que les erreurs de résolution de nom d'objet qui se produisent après la compilation en raison de la résolution de nom différée.

Espérons que cela aide quelqu'un d'autre à économiser quelques heures de débogage ...

Dans mon cas, l'erreur était causée par un RETURNà l'intérieur du fichier BEGIN TRANSACTION. Alors j'avais quelque chose comme ça:

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

et il doit être:

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

Pour moi, après un débogage approfondi, le correctif était un simple lancer manquant; instruction dans le catch après la restauration. Sans lui, ce vilain message d'erreur est ce que vous obtenez.

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

J'ai eu le même message d'erreur, mon erreur était que j'avais un point-virgule à la fin de la ligne COMMIT TRANSACTION

J'ai rencontré cette erreur une fois après avoir omis cette déclaration de ma transaction.

COMMIT TRANSACTION [MyTransactionName]

À mon avis, la réponse acceptée est dans la plupart des cas une exagération.

La cause de l'erreur est souvent une discordance entre BEGIN et COMMIT, comme l'indique clairement l'erreur. Cela signifie utiliser:

Begin
  Begin
    -- your query here
  End
commit

au lieu de

Begin Transaction
  Begin
    -- your query here
  End
commit

l'omission de Transaction après Begin provoque cette erreur!

Assurez-vous que vous n'avez pas plusieurs transactions dans la même procédure / requête dont une ou plusieurs ne sont pas validées.

Dans mon cas, j'ai accidentellement eu une instruction BEGIN TRAN dans la requête

Cela peut également dépendre de la façon dont vous appelez le SP à partir de votre code C #. Si le SP renvoie une valeur de type de table, appelez le SP avec ExecuteStoreQuery, et si le SP ne renvoie aucune valeur, appelez le SP avec ExecuteStoreCommand

Évitez d'utiliser

RETURN

déclaration lorsque vous utilisez

BEGIN TRY
    ... 
END TRY

BEGIN CATCH
    ...
END CATCH

et

BEGIN, COMMIT & ROLLBACK

instructions dans les procédures stockées SQL

Si vous avez une structure de code de quelque chose comme:

SELECT 151
RETURN -151

Puis utilisez:

SELECT 151
ROLLBACK
RETURN -151