Discussion :

[Matth_S]

Bonjour,

Je me pose un problème sur les transactions, j'ai lu les infos dessus sur msdn (http://msdn.microsoft.com/fr-fr/library/2k2hy99x.aspx), mais les exemples qui sont données utilisent un objet "sqlTransaction" qui sert pour plusieurs requêtes envoyées séparément dans plusieurs ExecuteNonQuery de l'objet command.

Ma question est :
est-ce que ce type de transaction est utile pour plusieurs requêtes envoyées simultanément dans le même ExecuteNonQuery ?
Ex :

Code :

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

1
2
3
4
 
SQL="UPDATE Table1 SET valeur=@nouvelle_valeur WHERE condition=@condition;UPDATE Table2 SET valeur=@nouvelle_valeur WHERE condition=@condition;"
myCommand.CommandText=SQL
myCommand.ExecuteNonQuery()

Est-ce qu'il est plutôt souhaitable d'utiliser un transaction en SQL directement (BEGIN TRAN T1 etc) ? Ou est-ce carrément inutile ?

Merci d'avance !

[bossun]

Je dirais que tout dépend du type de données que tu traites.

[Matth_S]

Merci pour ta réponse.

Les données que je traite sont des login / password
C'est assez mal pratique, mais j'ai 2 tables qui doivent stocker les identifiants login/password. Il faut donc si un utilisateur décide de modifier son login ou son password que je sois sur que la modif a eu lieu dans les 2 tables, d'ou l'idée d'une transaction pour éviter qu'un plantage ne me donne une mise à jour incomplète.

[bossun]

Dans ce cas là, je te suggère de faire cela dans une transaction...

Mais faire des transactions pour tout et n'importe quoi n'est pas vraiment optimal comme procédé.

[Matth_S]

Merci pour ta réponse ! Transacation donc !
Par contre tu as une idée si je dois gérer la transaction côté VB avec un objet connection ou côté SQL ? J'ai tendance à penser que je dois la gérer côté SQL puisque je balance 2 requêtes dans le même commandText, donc tout se passe niveau SQL Server.

[bossun]

tu peux gérer tes transactions au niveau VB mais tu peux le faire au niveau sql si tu as des procédure stockées. le résultat est le même.