bonjour,

    Pour moi je vois plusieurs erreurs.
    Si ton erreur survient sur <If maDtw.Update(True, False) <> 1 Then> comme tu effectue un return False tu ne pourras jamais rentrer dans la boucle

    En deux quand tu rentre dans ta boucle tu effectue un commit lequel vas mettre le sqldbcode à 0 donc tu vas passer dans le else et tu remet ton booleen à true donc tu sort de la boucle.

Cdt
Yanis

shahin :
Désolé pour le tableau de DTW, erreur de copier/coller sur le forum.
Un deadlock, dans mon cas, est apparemment l'accès concurrentiel à une ressource commune par au moins 3 points ; concrètement, notre applicatif (jusqu'à 16 postes en simultané, + triggers et tâches régulières annexes) effectue des UPDATE / DELETE sur une même table. C'est du moins la seule hypothèse qui nous a semblée plausible.

Yanis :
Si l'ordre d'update me retourne une erreur (duplicate key par exemple ou non respect d'une clef étrangère), j'effectue immédiatement mon rollback.
En fait je pensais que le COMMIT USING SQLCA me retournerait un DBCODE <> 0 si le serveur provoque une erreur comme un deadlock, mais d'après ce que vous semblez me dire, c'est l'UPDATE() qui me retourne l'info ?

Je vous ai présenté une version simplifiée de mon problème, car, en fait, lorsque je simule un deadlock et que j'exécute mon code au pas à pas, c'est bien sur la ligne du COMMIT que le deadlock est provoqué. En effet, dans mon commit, j'ai plusieurs datawindows que j'UPDATE() (ce qui déclenche update ou delete selon le cas) + SQL Embedded. A chaque tentative d'UPDATE(), si l'ordre est <> 1, je retourne le message d'erreur DB associé. Lorsque je tente le COMMIT, c'est donc ma transaction qui est deadlockée, et qui peut comporter donc plusieurs ordres SQL. Je me dois donc de retenter l'ensemble de ma transaction et non pas seulement l'update de maDtw. Pour dire, je stocke mon embedded dans un tableau de chaîne et je retente les ordres par un

PREPARE SQLSA FROM :ls_sql USING SQLCA;
EXECUTE SQLSA USING :ll_temp;

Merci, je vais tenter de déporter ma solution au niveau de l'update.

Salut,

   je ne me baserais pas sur le sqldbcode pour finir ma boucle

boolean    lb_fin
ll_essai = 10

Do
  If maDtw.Update(True, False) = 1 Then
      lb_fin = true
  Else  
    ll_sqldbcode = SQLCA.SQLDBCode

    // Attention ici tu fais un rollback mais si tu as fait des MAJ
    // avec du sql embeded tu perd tes modif et tu continue à mettre à jour ta datawindow 
    // si tu as eu un dead lock sur la fonction update. ????? 

    ROLLBACK USING SQLCA;
    If sqldbcode = 1205 Then  // DBCode POUR DEADLOCK
      If ll_essai = 0 Then
        MessageBox("", "Impossible d'enregistrer, verrou")
        Return 1
      Else
        MessageBox("", "Verrou temporaire, autre tentative")
        ll_essai --
      End If
    Else
      MessageBox("", "L'erreur suivante s'est produite :~r" + SQLCA.SQLErrText)
      Return 1
    End If
  End If
Loop Until lb_fin 
   
COMMIT USING SQLCA;

Pour moi un rollback n'a jamais généré de dealock au contraire puisqu'il enlève les lock posés dans la base par ta proc

Si tu veut faire un deadlock, je te conseille de prendre un outil tel que ISQL
     1 > Tu met à jour avec ISQL  ( tu dois choisr le bon enregistrement qui doit bloquer ton appli ) (tu n'es pas obligé de faire des modif tu peut faire un update avec les mêmes valeurs que celle contenue en base)
     2 > Tu met à jour avec ton appli ( elle doit au moins mettre à jour une ligne et se retrouver bloquer par le verrou poser avec ISQL
     3 > Tu essaye de mettre à jour avec ISQL l'enregistrement qui a été mis à jour par ton appli

Là tu as un cas de deadlock

je pense que tu as tout intérêt à le récupérer avant ton rollback