Discussion :

[Actarion]

Bonjour tout le monde,

Actuellement j'ai une application faite en VB 6 qui accède à serveur SQL 2K. Mon problème est que je recontre le message d'erreur suivant "La transaction (processus ID = 56) a été bloquée par un autre processus et a été choisie comme victime. Relancer la transaction" quand j'effectue un traitement de facturation.

Celà est très gênant, même si je récupère l'erreur, car je me retrouve avec une facturation incomplête et un casse tête pour l'utilisateur.
J'ai environ 200 transactions en 5 minutes sur toutes la bases qui se
lancent durant ce traitement, dont la moitié pour mon traitement.
Je multiplie les transactions pour évitez les attentes aux autres utilisateurs.

Donc ma question est de savoir comment éliminer ces blocages, ou alors au pire comment mdoifier ma procédure pour qu'elle soit prioritaire sur les autres, en cas de blocage c'est une autre qui est choisie comme victime.

J'attends vos réponses avec impatience parce que je me trouve dans une solution compliquée (facturation du semestre).

Merci.

[Invité]

Tu te trouves apparemment confronté à des problèmes de deadlocks. Cette recherche sur Google peut déjà t'aider. Et plus particulièrement ce lien.

[BalBalNet]

Bonjour.
Quel type de transaction utilses-tu ?

[Actarion]

Merci pour vos réponses.

Mais je n'avance pas bien, je ne connais pas bien le système de deadlocks et de plus avec mon anglais très moyen j'ai du mal à comprendre.

Sinon ce que je sais avec certitude c'est que ce problème arrive quand 2 transactions différentes veulent insérer une ligne dans la même table.

Pour le mode de transaction je ne saurais pas répondre, je peux juste dire que j'utilise les transactions à partir de VB directement et pas dans mes requêtes SQL.
J'utilise :
Dim ADOcnn As ADODB.Connection
ADOcnn.begintrans

Puis
ADOcnn.CommitTrans
ou
ADOcnn.RollbackTrans

J'ai toujours une gestion d'erreur pour effectuer un de ses 2 opérations et ne pas laisser de transaction en cours.

[Invité]

Change le niveau d'isolation des transactions.

[BalBalNet]

Le problème pourrait encore arriver. Il faut donc prévoir le coup.

Et trapper l'exception SQL levée dans ce cas (code 1205). Tu peux dans ce cas annuler ta transaction (vaut mieux être sûr) et relancer ta procèdure.

[Actarion]

Merci pour la réponse, ça je veux essayer de la faire et ça devrait aller.

Par contre ça m'amène à la question suivante, depuis 1h j'essai de reproduire mon cas de deadlock sur mon serveur de dev mais sans succès. Est-ce que j'aurais un moyen de le reproduire afin de tester que ma correction fonctionne correctement ?

[BalBalNet]

Si tu ne modifies pas ton niveau d'isolation de transaction, c'est qu'il est "RepeatableRead" par défaut. Si tu lances ta transaction en niveau "Serializable", tu as plus de chance d'être gêné par les deadlocks (donc n'oublie pas de l'enlever après tes tests).
Mais si tu testes seul...tu vas avoir du mal ou alors en lançant des requêtes en parallèle via l'analyseur.