Discussion :

[judy13]

Bonjour à tous
J'ai un problème au niveau d'une transaction sql : j'ai une application réalisée en VB6 avec une conection Adodb sur une base Sql server 2000, il y a une procédure qui enregistre des données dans 6 tables , le tout dans une transaction , environ une fois sur 10000 opérations je trouve que seulement les 2 derniers requêtes sql sont enregistrés dans la base , j'ai fait une trace sql, j'ai trouvé que les 6 requetes ont été exécutés et la transaction se Commit normalement, sauf que j'ai remarqué en comparant avec la trace des requêtes qui ont affecté les 6 tables qu'il y a 2 lignes vides juste avant les 2 dernières requete : voici la structure de la trace : ( j'ai pas mis les requêtes pour simplifier )

Ligne EventClass TextData
1 12 set implicit_transactions on
2 50 NULL
3 50 NULL
4 50 NULL
5 12 Insert into table1
6 12 Insert into table2
7 12 Update Table3
8 12 Update Table4
9 50 NULL
10 12 Select from table5
11 50 NULL
12 12 Update Table5
13 12 Update Table6
14 50 NULL
15 12 IF @@TRANCOUNT > 0 COMMIT TRAN
16 12 set implicit_transactions off



Seulement table5 et Table6 on été affecté, a noter que la durée d'exécution de la ligne 9 et de la ligne 10 sont anormalement élevés( 1seonde chacune) et la différence par rapport à une transaction qui a affecté les 6 tables : les ligne 9 et 11 n'existent pas
ça fait des mois que j'essaie de trouver une solution en vain, Merci pour votre aide

[elsuket]

Bonjour,

Le fait que la colonne TextData de la trace ne soit pas valuée pour certaines lignes n'indique pas un problème.
Si vous regardez dans les filtres que vous pouvez ajouter, dont ceux que vous pouvez poser sur la colonne TextData, il y a une coche "Exclure les lignes vides"

Pourriez vous nous donner le code de votre procédure stockée, et éventuellement la structure des tables ?
Est-ce que ces erreurs se produisent à une heure de forte activité sur le serveur ?
Y'a-t-il des deadlocks ? (catégorie Locks / evénements deadlock graph et deadlock chain).

@++

[judy13]

Bonjour , Merci pour votre réponse, d'abord concernant l'activité du serveur je peux pas affirmer que l'erreur se produit durant une heure de grande activité, le système fonctionne de façon régulière durant toute la journée peut être au moment de l'erreur il y a eu un traitement qui a chargé le serveur, la trace que j'ai faite je l'ai appliqué seulement sur l'application en cause, il ya plus de 50 utilisateurs avec des centaines de transactions par minutes donc ça sera pas évident de tout tracer, mais je vais ajouter les événements de verrous sur ma trace et attendre que l'erreur se produise de nouveau, , en moyenne ça arrive 2 fois par mois, concernant le code c'est pas une procédure stocké mais un code vb , le voici ci joint , la structure des tables aussi et la trace complète de l'opération qui a causé le problème, à noter qu'il y a des petits déclencheurs sur quelques tables mais je pense pas que la cause du problème car ils sont simples et ne font qu'une opération d'insertion dans d'autres tables utilisées pour une opération de réplication.
et Merci

[SQLpro]

Dans votre code VB vous ne gérez pas les erreurs. Il est donc possible que des requêtes ne s'effectuent pas suite à une erreur alors que vous validez systématiquement la transaction.

C'est d'ailleurs une hérésie que de faire des transactions côté client. C'est comme cela que l'on flingue les performances d'une base de données.

Passez tout ceci dans une procédure stockée, démarrez la transaction dans la proc stock et testez les exceptions pour chaque commande SQL.

Lisez ce que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/s...chniques/#L1.7

Pour développer des procédures stockées, c'est simple... Lisez ce que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/s...ransactsql/#L4

A +