Discussion :

[benabdessamed]

bonjour StringBuilder,

lorsque j'utilse "begin transaction" toutes les lignes de la table devient non modifiable.

[StringBuilder]

Bien sur que non.

[StringBuilder]

Et il y a une différence entre :
- Je lock les lignes que j'ai modifié jusqu'à ce que je valide/invalide la transaction
- Je lock les lignes que je lis, jusqu'à ce que je valide/invalide la transaction

Le premier cas est implicite avec les transactions.

Le second cas n'est pris en charge que par hint : il faut indiquer au SGBD qu'on lock ou non la table/page/ligne qu'on lit.

[SQLpro]

...
Le second cas n'est pris en charge que par hint : il faut indiquer au SGBD qu'on lock ou non la table/page/ligne qu'on lit.

Pas tout à fait... En niveau d'isolation READ COMMITTED ou SERIALIZABLE les lignes lues sont verrouillées jusqu'à la fin de la transaction.

A +

[benabdessamed]

mon problème est que lorsque j'utilise "begin transaction" et que j'ai deux utilisateurs qui ont l'accès en exclusivité à deux lignes différentes d'une même table, l'un après l'autre. par conséquence le deuxième ne peut modifier la ligne dont il a l'accée. .

merci.

[StringBuilder]

Poste ton code, qu'on sache au moins comment tu verrouilles tes lignes.

En tout cas "begin transaction", sans instruction derrière, ne provoque absolument aucun verrou.

[benabdessamed]

bonjour,
mon code est :
BEGIN TRAN

SELECT * FROM PCC_COM WITH (HOLDLOCK, ROWLOCK) WHERE CODE = '10'

COMMIT TRAN

durant exécution de "select" et avant "COMMIT TRAN" la table est verrouillé.

merci pour votre aide

[StringBuilder]

Le responsable, c'est ton "with".

Il provoque un verrou exclusif sur la ligne lue.

Plus exactement, sur la page lue, car par défaut, SQL Server ne fait pas des verrous à la ligne, mais à la page.

Cf. blog de SQLPro pour plus d'informations sur le sujet.

[SQLpro]

Bonjour,

J'ai toujours utilisé les locks manuels avec un hint.

Par exemple, lorsque mon utilisateur entre en "modification" sur la fiche d'un client, je veux que ce client ne puisse :
- pas être modifié
- pas être sélectionné
(toute tentative allant dans l'un ou l'autre des des sens devra être mise en attente tant que mon utilisateur n'aura pas terminé la modification)

Donc dans le code client :

1/ Au chargement de la fiche client (en mode modification)

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
begin transaction;
select id, nom, age from client with rowlock holdlock;

A partir de là, la ligne en question est lockée. Personne ne peut plus rien faire dessus, ni sélection, ni modification.

2/ La mise à jour : à l'intérieur de la transaction

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
update client set name = 'toto', age = '31' where id = 1;

Ici, c'est toujours locké.

3/ Libération du verrou lorsqu'on quitte la fiche du client :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
rollback;
-- ou
commit;

Là, tout le monde peut de nouveau accéder à la ligne.

Attention cependant : ce genre de verrous ralenti considérablement la base de données, et peut aboutir sur un dead lock !

Ce que tu fais est une véritable horreur !!!
En effet un simple SELECT * sur la table devient impossible !

J'ose espérer qu'en tant que chef de projet tu n'a pas implémenté cela en production ?


A +

[benabdessamed]

bonjour;
j'ai trouver la solution; il faut que la table a une clé.

[benabdessamed]

bonjour,
et maintenant, je veux savoir comment je peux savoir si une ligne est verrouillé ou non.

merci.