Discussion :

[Bluedeep]

Désolé de ne pas pouvoir t'aider plus (pas mal de travail et un gros doc de SFD à terminer sur mon bureau) mais je me souviens avoir galérer avec cela.

De mémoire le SAVE peut se faire sur un nom arbitraire.

je te suggère d'aller voir vraiment dans MSDN le détail, car je balance des bribes qui me reviennent peu à peu et risque de t'induire en erreur.

EDIT : n'oublions pas les tuto de THE SPECIALIST DE DVP sur SQl server, M. SqlPro. chapitre 4.6

http://sqlpro.developpez.com/cours/s...r/transactsql/

Sinon, j'ai trouvé cela aussi :

http://sqlserverpedia.com/wiki/Nesting_Transactions
http://www.sqlservercurry.com/2011/0...in-stored.html

recherche : "sql server rollback nested transactions"

[StringBuilder]

Bon, ben en fait, le problème est plus grave que ça...

J'ai l'impression que SQL Server patine dans la choucroute tout ce qu'il peut avec les transactions imbriquées.

La syntaxe "classique" ne fonctionne absolument pas quand on l'utilise directement 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

Ca plante sur le premier rollback.

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
    insert into test (name) values ('test 2');
  save transaction b
  rollback transaction b
commit transaction a

Ca passe, mais la transaction est jugée "non terminée".

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
    insert into test (name) values ('test 2');
  save transaction b
  rollback transaction b
commit transaction a
commit transaction a

Ca 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 !

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
    insert into test (name) values ('test 2');
  save transaction b
  rollback transaction b
save transaction a
commit transaction a

Ne marche pas

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

J'utilise la 2008 R2 Express

[Bluedeep]

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

J'utilise la 2008 R2 Express

Je te suggère de :

- lire les liens que je t'ai passés
- ouvrir une discussion dans la partie Sql Server du forum, où ce genre de problème pointu devrait trouver son interlocuteur.

[StringBuilder]

J'ai envoyé un MP à SQLPro en espérant qu'il aura 5 minutes pour regarder ce problème.

Je viens de lire les articles que tu m'as suggéré, mais je ne trouve aucune explication quant à mon problème.

Même pire, dans le point qui utilise un SAVE, c'est l'utilisation "normale" du SAVE qui est faite, c'est à dire qui permet de rollback une partie seulement de la transaction.

[Bluedeep]

J'ai envoyé un MP à SQLPro .

Jene sais pas si c'est une bonne idée : l'homme est ultra-compétent mais chatouilleux. Il eut été préférable, AMHA, d'ouvrir un thread sur le sujet (qui aurait profité à tout le monde, dont moi d'ailleurs).

[BenoitM]

Jene sais pas si c'est une bonne idée : l'homme est ultra-compétent mais chatouilleux. Il eut été préférable, AMHA, d'ouvrir un thread sur le sujet (qui aurait profité à tout le monde, dont moi d'ailleurs).

Tu oses aller dans cette partie enfouie du forum où se trouvent quelques pervers du SQL?

[StringBuilder]

Jene sais pas si c'est une bonne idée : l'homme est ultra-compétent mais chatouilleux. Il eut été préférable, AMHA, d'ouvrir un thread sur le sujet (qui aurait profité à tout le monde, dont moi d'ailleurs).

Je déteste les MP aussi, et c'est pour ça que je l'ai invité à venir dans le topic, je ne lui ai pas exposé le problème ni posé de question dans le MP

J'ai aussi créé un topic dans le forum dédié à SQL :
http://www.developpez.net/forums/d11...s/#post6519610

[Bluedeep]

Tu oses aller dans cette partie enfouie du forum où se trouvent quelques pervers du SQL?

J'arréterai le jour où on me présentera un langage capable d'en faire autant, aussi vite, et avec aussi peu de lignes que le SQL.

A mon avis, c'est pas demain....

[StringBuilder]

D'après le forum dédié au SQL, en fait, SQL Server ne supporte pas les transactions imbriquées.

En fait un BEGIN TRANSACTION après un précédent BEGIN TRANSACTION est tout bonnement ignoré !

Il faut donc faire :

Code :

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

1
2
3
4
5
6
7
8
9
 
begin transaction
[...]
save transaction a
[...]
save transaction b
[...]
rollback transaction a
commit

Par exemple.

Ce qui reviens donc au Save() qu'on trouve dans SqlTransaction

Et qu'il faut donc utiliser tel quel.

Seul hic, pour la majorité des cas, cette approche ne pose pas de problème. Mais parfois, les transactions réellement imbriquées sont très utiles.

C'est d'autant plus utile lorsqu'on a du code "dynamique", et qu'on ne sais pas trop où on en est dans les Save()...

[StringBuilder]

Bon, ben pour ceux qui n'ont pas envie de se prendre la tête avec des save à ne plus savoir où ils en sont, voici une petite contribution de ma part, qui masquera les savepoint, et vous présentera de véritables fausses transactions imbriquées.

http://www.developpez.net/forums/d11...p/#post6519939

[Invité]

Bon je viens du forum SQL

Loin d'être un expert en SQL donc j'emrpunte la signature de BenoitM : Je ne suis qu'un pauvre débutant alors ne frappez pas si mes idées ne sont pas bonnes

Ok de ce que j'ai compris avec les transactions imbriquées elles sont considérées comme des transactions filles d'une transaction mère. Donc dans la logique (encore de ce que j'ai compris et que je crois logique) une transaction mère n'est validée que si toutes les transactions filles (donc imbriquées) sont validées avec succès !
Après tout c'est par la définition même d'une transaction :

Une transaction informatique consiste à effectuer une opération informatique cohérente composée de plusieurs tâches unitaires. L'opération ne sera valide que si toutes les tâches unitaires sont effectuées correctement (on parle alors de commit). Dans le cas contraire, l'ensemble des données traitées lors de l'opération reviennent à leur état initial (on parle alors de rollback).

Dans la continuité dans .Net, cette même logique est utilisée avec les TransactionScope lorsqu'on les imbrique. On arrive même à simuler la fameuse clause SQL SAVE qu'il est question maintenant dans ce thread pour cela il suffit juste dans une TransactionScope imbriquée d'utiliser l'option RequireNew.

[StringBuilder]

Lorsqu'on a des transactions imbriquées, le comportement n'est pas celui-ci.

Lorsqu'une transaction "parent" est rollbackée, tout ce qui a été fait dedans, y compris dans les transactions filles non terminées ou committées est annulé.

Lorsqu'une transaction "parent" est committée, tout ce qui a été fait dedans, y compris dans les transactions filles qui ne sont pas terminées ou committées, est validé.

Mais pour plus de propreté, on valide/rollback systématiquement à chaque niveau.

TransactionScope me gêne pour deux raisons :
- Il n'est pas lié à une connexion
- Il n'est pas dans le namespace System.Data

Ceci implique que :
- Ce n'est pas le moteur du SGBD qui effectue les transactions (même si le moteur de TransactionScope délègue ensuite au SGBD)
- Si j'utilise plusieurs connexions en même temps, je suis incapable de choisir la granularité de mes connexions (tout est mis en transaction, ce qui est lourd à gérer pour un SGBD)
- Si j'ai un certain nombre de requêtes à jouer en dehors de la transaction, je ne peux pas. Par exemple, si je veux loguer dans une table mes actions, je veux conserver ces actions même en cas de rollback. C'est impossible avec TransactionScope
- Le fait qu'il ne soit pas dans le namespace lié à l'accès aux sources de données montre qu'il est soit capable, soit prévu qu'il puisse gérer en transaction d'autres éléments que les accès aux données (accès aux fichiers, mémoires, etc. ?) Et je ne veux pas que l'étendue de la transaction puisse toucher des éléments que je ne veux pas.