Discussion :

[StringBuilder]

Bonjour,

Dans un programme C#, j'ai tenté de faire des transactions imbriquées comme je le faisait en 1999 avec VBScript et le connecteur OLEDB pour SQL Server 7.0

Seul hic, j'ai une erreur comme quoi c'est pas supporté par l'objet.

Qu'à cela ne tienne, je tente de le faire "à la main" en SQL.

Voici l'étendue des mes connaissances à propos des transactions, telles que je les ai apprises.
Il me semble qu'avec SQL Server 7 ou 2000, ça marchait... A moins que je ne confonde avec Oracle (????) J'avoue que j'ai de plus en plus de doutes.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
begin transaction A
  insert into matable (champ) values ('valeur a');
  begin transaction b
    insert into matable (champ) values ('valeur b');
  rollback transaction B -- on annule l'insertion de 'valeur b'
commit transaction A -- on valide l'insertion de 'valeur a'

=> Bref, à la fin du script, on n'a que "valeur a" dans la base.

Seul hic, SQL Server n'a pas l'air de l'entendre de cette oreille :

Voici ce que j'ai tenté de faire, dans Entreprise Manager :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
begin transaction a
  insert into test (name) values ('test 1');
  begin transaction b
    insert into test (name) values ('test 2');
  rollback transaction b
commit transaction a

Ça plante sur le premier rollback. Pourquoi ?

Impossible de restaurer b. Ni transaction ni point d'enregistrement de ce nom n'a été trouvé.

J'ai donc tenté, selon les conseils de Bluedeep :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
begin transaction a
  insert into test (name) values ('test 1');
  begin transaction b
  save transaction c
    insert into test (name) values ('test 2');
  rollback transaction c
commit transaction a

Ça passe, mais la transaction est jugée "non terminée". Aussi, je ne vois pas ce que vient faire un savepoint au milieu...

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
begin transaction a
  insert into test (name) values ('test 1');
  begin transaction b
  save transaction c
    insert into test (name) values ('test 2');
  rollback transaction c
commit transaction a
commit transaction a

Ça passe, et cette fois la transaction est bien terminée.
Sauf que je vois pas comment je pourrais générer programmatiquement ce double commit (et surtout, je vois pas à quoi il sert !)

D'autaut que si j'en met un 3°, ça plante !

Bref, quelqu'un peut me donner la syntaxe qui marche pour imbriquer des transactions dans SQL Server ?

J'utilise la 2008 R2 Express

[StringBuilder]

Voici ce que je cherche à faire :

Transaction PARENT qui contient une transaction FILLE :

FILLE : commitée
PARENT : rollbackée
=> Rollback général

FILLE : rollbackée
PARENT : committée
=> Seule PARENT est sauvegardée

FILLE : committée
PARENT : committée
=> Tout est sauvegardé

FILLE : rollbackée
PARENT : rollbackée
=> Tout est annulé

Le but du jeu, c'est d'arriver à trouver la syntaxe pour pouvoir :
- avoir autant de FILLE que désiré dans PARENT
- avoir autant de niveaux d'imbrications que désiré PARENT > FILLE > PETITE_FILLE > ARRIERE_PETITE_FILLE > etc.

Afin de pouvoir faire des traitements complexes avec des transactions imbriquées, liées à des actions dans la GUI du programme.

[Jean.Cri1]

Si c'est comme sybase ...

Le rollback affecte toutes les transactions en cours,
avec un nom de transaction le nom DOIT etre celui de la premiere transaction.

Pour faire un retour partiel il faut faire des

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

save tran savepoint_name

a effectuer -je crois- avec rollback savepoint_name

Apres j'ose imaginer que le code reprend à la suite de l'instruction rollback ,
je ne l'ai jamais utilisé.

[Serguei_TARASSOV]

Effectivement, dans SQL Server il n'y a pas des vrais transaction imbriquées. L'annulation d'une transaction imbriquée annule toutes les autres transactions.

[StringBuilder]

Ça, c'est l'implémentation que propose effectivement le connecteur .NET : passer par des savepoint.

Le seul problème, c'est que ça ne gère que les scénari séquentiels, c'est beaucoup plus limité que les transactions imbriquées.

Le truc qui m'étonne, c'est qu'avec la version 7 ou 2000, je ne me souviens plus, je suis quasi certain que je gérais sans problème des connexion imbriquées...

Je deviens complètement fou ?

[Jean.Cri1]

Si les save tran savepoint_name permettent de rollbacker jusqu'au savepoint_name , et que le code repart à la suite du rollback savepoint_name
...
alors imbriqué ou sequentiel c'est pareil non ? avec un save point a la place du begin tran (fille )

[StringBuilder]

Le seul truc que je pige quand même pas, c'est pourquoi SQL Server propose une variable @@tran_count ou un truc du genre, qui permet de connaître le niveau d'imbrication de transaction... puisqu'il ne supporte pas les transactions imbriquées

Et encore plus drôle, pourquoi il ne supporte pas les transactions imbriquées alors qu'on peut parfaitement, au sein d'une transaction, appeler une procédure qui crée sa propre transaction, et ainsi de suite... et donc avoir de vraies transactions imbriquées

[iberserk]

Et encore plus drôle, pourquoi il ne supporte pas les transactions imbriquées alors qu'on peut parfaitement, au sein d'une transaction, appeler une procédure qui crée sa propre transaction, et ainsi de suite... et donc avoir de vraies transactions imbriquées

Non justement ce n'est pas ce que l'on appel des transactions imbriquées puisqu'un ROLLBACK annulera toutes les transactions ouvertes (principe d'Atomicité).

D'ou l'utilité du @@trancount qui permet de savoir dans une procédure stockée le contexte d’exécution.

Vous lancez des transactions à partir d'un code .NET?
Quid d'un plantage de l'application? qui fera le rollback???