Cursor lock de table

Bonjour à tous,

Je ne suis pas certain mais j'ai le sentiment que dans l'utilisation de mon curseur je LOCK les tables qui sont utilisées dans celui-ci.
Est ce que c'est possible ? Si oui, comment est ce qu'on résout ce problème.

Pour info, dans mon curseur je fais ceci:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

OPEN c_cursor_cpt FETCH NEXT FROM c_cursor_cpt INTO @cpt_id   -- Pour chaque compteur -- -------------------- WHILE @@FETCH_STATUS = 0 BEGIN   SELECT * FROM xxxx   SELECT * FROM xxxx   IF xxxxxxx BEGIN   INSERT INTO xxxxx   END   FETCH NEXT FROM c_cursor_cpt INTO @cpt_id

---

il y a 99.9 % de chance que vous pourriez vous passez d'un cursor en réécrivant votre code ;)

Bonjour,

Le type de verrouillage dépend du déclare cursor. S'il est "for read only" les threads concurrents peuvent lire les tables.
Ensuite, il faut vérifier le type d'isolation de la transaction, si vous êtes en "UR" (très peu probable), aucun verrou n'est posé, sinon consultez la documentation ici

Les verrous liés au curseur sont libérés au CLOSE CURSOR ou au COMMIT ou ROLLBACK de la transaction.

J'ose espérer que le SELECT * dans le curseur n'est pas conforme à la réalité ;)

Et, comme suggéré par 7gyY... si vous pouvez vous passer d'un curseur, ce sera beaucoup, beaucoup, mais alors beaucoup plus rapide !

J'entends de plus en plus qu'il faut réécrire les procédure stockée avec un curseur.
Mais je me pose alors la question, pourquoi Microsoft prévoit les curseurs si au final on ne les utilise pas ?

Citation:

---

J'ose espérer que le SELECT * dans le curseur n'est pas conforme à la réalité

---

Non bien entendu c'était uniquement à titre d'exemple.

Voici comment je fais le déclare de mon curseur:

Code:

---

1 2 3 4

DECLARE c_cursor_cpt CURSOR FOR SELECT compteur_id FROM @cpt_table

---

Du coup là est ce que je suis en "for read only" ?

Citation:

---

Envoyé par Pfeffer

J'entends de plus en plus qu'il faut réécrire les procédure stockée avec un curseur.

---

Parce que c'est le MAL ! Il y a plein d'exemples sur les internets qui montrent comment ça plomble énormément les performances
Par exemple : https://www.sqlshack.com/using-sql-s...disadvantages/

Citation:

---

Envoyé par Pfeffer

Mais je me pose alors la question, pourquoi Microsoft prévoit les curseurs si au final on ne les utilise pas ?

---

J'imagine que 1) c'est dans la norme SQL et 2) il y a quelques cas où on ne peut pas s'en passer (requête dynamique sur plusieurs bases de données)

Par défaut les curseur sont ouvert dans le pire des modes :
live sur les données, donc verrous
mise à jour possible à travers le curseur
curseur scrollable
scope à travers les routines


Généralement un curseur :
LOCAL FORWARD_ONLY STATIC READ_ONLY
Suffit et économise des ressources et des verrous

A +