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