Verrou / lock update / delete

Bonjour à tous. J'ai un gros pépins sur un de mes devs.

Voila le topo:

j'ai un script vb qui lance deux requêtes:

Code:

---

UPDATE TOTO WHERE X=1

---

et de suite après:

Code:

---

DELETE FROM TOTO WHERE X=1

---

Le tout est compris dans une transaction coté vb.

Sauf que le delete est bloqué par un verrou sur la ligne. Le verrou vient de l'update.

Cela donne:

Citation:

---

Expiration du délai d'attente. Le délai d'attente s'est écoulé avant la fin de l'opération ou le serveur ne répond pas.

---

Je n'ai fait aucune demande explicite de verrou dans mes requêtes.
La question folle qui me viens à l'esprit et:

sql ne supporte pas un update + delete sur la même ligne dans la même transaction???? :calim2:

Merci de votre aide. Wells

Bonjour,

Ceci est tout à fait normal si vous êtes dans le cas d'une transaction et que vous n'avez pas committé la 1ère transaction qui fait votre update.

++

Oki, j'ai une question subsidiaire alors, imaginons:

je fait:

UPDATE
commit
DELETE
plantage quelconque

est ce que mon UPDATE sera rollbacker?? (pas très français ca! lol)

Une petite question, quel est l'intérêt d'effectuer un UPDATE immédiatement suivi d'un DELETE ?

Faites directement le DELETE.

Même question que Waldar ..

Pourquoi faites vous cela ?
Expliquez nous ce que vous voulez faire exactement ..

++

C'est assez complexe, l'UPDATE entraine d'autres requêtes (modif de stock).

Une fois c'est modif faites, le delete passe pour faire le ménage (avec d'autres modifs en prime)

Citation:

---

C'est assez complexe, l'UPDATE entraine d'autres requêtes (modif de stock).

---

Humm ca sent le transfert de stock ou quelque chose du genre ... :)

Citation:

---

Oki, j'ai une question subsidiaire alors, imaginons:

je fait:

UPDATE
commit
DELETE
plantage quelconque

---

Si vous le faites dans une même transaction oui mais il faut modifier la phase de commit

1- BEGIN TRAN
2- UPDATE
3- IF @@ERROR <> 0 ROLLBACK et STOP
4- DELETE
5- IF @@ERROR <> 0 ROLLBACK et STOP
ELSE COMMIT

Si vous le faites dans 2 transactions distinctes non

++

Je dirai plutôt que ça sent le trigger qui fait 3000 opérations, et que ces-dites opérations seraient beaucoup plus à l'aise dans une procédure stockée !

Bonjour,

Citation:

---

C'est assez complexe, l'UPDATE entraine d'autres requêtes (modif de stock).

Une fois c'est modif faites, le delete passe pour faire le ménage (avec d'autres modifs en prime)

---

Même remarque que Waldar ;)

@++ ;)

En mettant les deux requête dans la même transaction, ca marche mieux....forcement :p