Discussion :

[spring.time]

Bonjour

les transactions jouent un rôle important parce qu'elles permettent de protéger homogénéité des données.
est ce qu'il faut créer à chaque appel d'une requête de création ou de manipulation des données, un objet SqlTransaction et l'attacher à l'objet Sqlcommande ou DataReader, c'est bien cela? et après l’exécution de la requête j'applique commit sur la transaction.

c'est correct?
est ce que vous pourriez me donner un exemple de select et de insert?

Merci

[meziantou]

Tu as un exemple d'utilisation sur MSDN
http://msdn.microsoft.com/fr-fr/libr...ansaction.aspx

Une autre façon de faire est d'utiliser TransactionScope
http://msdn.microsoft.com/fr-fr/libr...tionscope.aspx

[Pol63]

les transactions ne sont pas utiles tout le temps
sur les select c'est inutile
sur une requete unique aussi

si tu fais "update machin"
soit tout est update soit rien, donc faire une transaction ne sert à rien
par contre si tu mets plusieurs requetes de modifications (insert/update/delete) dans un seul commandtext, ou que tu executes plusieurs requetes de modification sur le même objet connection, ca peut etre utile si tu veux etre sur que toutes les requetes agissent ou aucune

[spring.time]

d'accord,
par exemple je fais une insertion, et ensuite je veux récupérer l'identifiant de la ligne insérée, j'ai pensé à faire une transaction pour l'insertion et ensuite après commit je récupère l'identifiant.

[rv26t]

Bonjour,

d'accord,
par exemple je fais une insertion, et ensuite je veux récupérer l'identifiant de la ligne insérée, j'ai pensé à faire une transaction pour l'insertion et ensuite après commit je récupère l'identifiant.

Dans ce cas une transaction est inutile, la commande est exécuté avec la méthode ExecuteNonQuery qui renvoie le nombre de ligne [Edit] impactées [/Edit] (dans ton cas 1) si en résultat tu obtients 1 (la requête insertion s'est bien passé) tu peux récupérer l'identifiant.

...
les transactions jouent un rôle important parce qu'elles permettent de protéger homogénéité des données.
...

Tout à fait.

Prenons un exemple.

Un client a passé une commande de 10 types de produits différents avec une certaines quantités par produits. (commande enregistré dans la base de données) ok.

Le lendemain il rappele et change sa commande : il ne veut plus 2 types de produits, modifier la quantité pour 4 types de produits, et commander 3 autres nouveaux type de produits.
Dans ce cas il faut faire une transaction qui comprendra 2 delete(s), 4 update(s) et 3 insert(s)
Si tout ce passe bien commit (tout est enregistré).
S'il y a un souci (un update provoque une erreur par exemple) rollback : la base reste comme à l'origine.

[Pol63]

d'accord,
par exemple je fais une insertion, et ensuite je veux récupérer l'identifiant de la ligne insérée, j'ai pensé à faire une transaction pour l'insertion et ensuite après commit je récupère l'identifiant.

dans le commandtext il y aura

Code :

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

1
2
insert into ...
select scope_identity()

puis un executereader (ou scalar)
la transaction n'est pas forcément utile car si l'insert plante la transaction n'est pas utile, si l'insert passe et que le select passe non plus
reste le cas ou l'insert passe et pas le select (moins de 0.0001% de chance que ca arrive je pense), si l'id est utilisé côté .net, c'est à toi de décider si tu veux annuler l'insert ou ne pas exécuter la suite du code .net

c'est réellement s'il y a plusieurs insert/update/delete à la suite que les transactions sont en général utilisées