seule la transaction de niveau 1 (@@trancount) est une transaction, un
rollback déferait toute transaction de niveau supérieur, même commitée.

br

"Fred.M." <FredM@discussions.microsoft.com> wrote in message
news:39203A09-4ADB-482F-AF0D-F2BD6FEC1A63@microsoft.com...
> Si ta question revient à dire "peut-on imbriquer plusieurs transactions
> les
> unes dans les autres ?", la réponse est oui. J'en reviens tout de même et
> dans ce cas à mon "CEPENDANT" de tout à l'heure : gare à la génération de
> verrous exclusifs !!
>
> FRED.M.
>
> "Patrick" a écrit :
>> Est-ce qu'on peut faire plusieurs ajouts et suppressions avant un
>> "COMMIT"
>> final et qui englobe le tout ?
>>
>> Merci.
>>
>> --
>> Patrick
>>
>>
>> "Fred.M." wrote:
>>
>> > Bonjour Patrick,
>> > La réponse est "ça dépend", et les éléments de décision sont les
>> > suivants :
>> >
>> > 1.) Par défaut la valeur de l'option de session "SET
>> > IMPLICIT_TRANSACTIONS"
>> > est à OFF. Cela induit que toute transaction est par défaut
>> > "auto-committée".
>> > Donc toute mise à jour est automatiquement validée.
>> >
>> > 2.) Si en effet tu utilises les transactions :
>> > Une transaction a notamment pour but de garder les données de ta base
>> > en un
>> > état cohérent et consistant. Ainsi, si deux opérations sont
>> > indissociables
>> > fonctionnellement parlant, elles doivent se situer dans la même
>> > transaction.
>> > Ainsi si le system plante en plein milieu du processus, soit tout est
>> > validé,
>> > soit rien ne l'est.
>> > Ex : soient 2 opérations pour un archivage, ou l'on historiserait par
>> > exemple des opérations obsolètes dans une table d'archive.
>> > a) insert into Table_Archive select * from Table_Source Where Madate...
>> > b) Delete From Table_Source where Madate....
>> > Si chacune de ces opérations sont dans des transactions différentes
>> > (donc si
>> > tu mets un commit après ton "Insert") et que ton serveur plante entre
>> > ton a)
>> > et ton b), tes données sont insérées en archive mais pas épurées de ta
>> > table;
>> > tu auras donc des données en double. Imagines que ça peut être bien
>> > pire si
>> > tu inverses le a) et le b) : tu supprimerais tes données sans les
>> > archiver !
>> > Ceci n'est qu'un exemple simple, mais dans cet exemple il convient de
>> > mettre
>> > ces opérations dans la même transaction.
>> > CEPENDANT !... Implémenter une transaction implique au niveau du moteur
>> > SQL
>> > une génération de verrous exclusifs, qui sont susceptibles de bloquer
>> > les
>> > autres sessions le temps de la transaction. Implémenter des
>> > transactions trop
>> > longues risquerait donc de ralentir ton application.
>> >
>> > CONCLUSION :
>> > - Si des ajouts / suppressions n'ont aucun rapport les uns avec les
>> > autres,
>> > alors en effet tu peux commiter après chaque opération.
>> > - Si a contrario fonctionnellement parlant tes opérations de ajouts /
>> > suppressions sont conditionnées entre elles, encapsulent les dans une
>> > seule
>> > et même transaction. Et s'il s'avère que cette transaction est
>> > relativement
>> > longue, alors essaie de planifier son exécution sur une période creuse
>> > (la
>> > nuit en général) pour éviter les locks.
>> >
>> > J'espère avoir été suffisamment clair dans l'ensemble.
>> >
>> > FRED.M.
>> >
>> >
>> > "Patrick" a écrit :
>> >
>> > > Bonjour,
>> > >
>> > > Je fais une succession de mises à jour d'une table qui ajoutent et
>> > > suppriment des enregistrements. J'utilise les transactions.
>> > >
>> > > Est-ce qu'il faut utiliser un "COMMIT" apres chaque mise à jour
>> > > (ajout ou
>> > > supression) ou bien est-ce qu'on peut faire un seul "COMMIT" Ã la fin
>> > > ?
>> > >
>> > > Merci.
>> > >
>> > > --
>> > > Patrick