Consultation des verrous

Le
Microsoft
Bonjour,

Dans le cadre d'une application, nous aimerions que lorsqu'un utilisateur
modifie une fiche, les autres utilisateurs ne puisse plus entrer en
modification sur cette meme fiche.

Nous avons alors penser a mettre une transaction dans notre code au moment
du passage en modification.
La premiere operation de cette transaction est de faire un 'select' sur un
des champs afin de poser un verrou partagé et ainsi empecher qu'un verrou
exclusif soit accepté.
Cependant, pour eviter d'avoir un message d'erreur SQL Server et plutot
mettre le notre, nous aimerions interroger la base, au moment de passer en
modif.

Quelle instruction devons nous utiliser ?
Comme information, nous avons le nom de la table mais nous n'arrivons pas a
faire le lien avec sys.dm_tran_locks

Par avance merci
Franck
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
bruno reiter
Le #11839021
Ce mode de verrouillage "pessimiste" est dangereux en terme de performances
qd le nb d'utilisateurs augmente.

Le mieux si tu gardes ce mode de fctionnement est de mettre SET LOCK_TIMEOUT
à 1 et de trapper l'erreur 1222 en cas de lock.

br

"Microsoft" news:%23X%
Bonjour,

Dans le cadre d'une application, nous aimerions que lorsqu'un utilisateur
modifie une fiche, les autres utilisateurs ne puisse plus entrer en
modification sur cette meme fiche.

Nous avons alors penser a mettre une transaction dans notre code au moment
du passage en modification.
La premiere operation de cette transaction est de faire un 'select' sur un
des champs afin de poser un verrou partagé et ainsi empecher qu'un verrou
exclusif soit accepté.
Cependant, pour eviter d'avoir un message d'erreur SQL Server et plutot
mettre le notre, nous aimerions interroger la base, au moment de passer en
modif.

Quelle instruction devons nous utiliser ?
Comme information, nous avons le nom de la table mais nous n'arrivons pas
a faire le lien avec sys.dm_tran_locks

Par avance merci
Franck



Fred BROUARD
Le #11838781
Microsoft a écrit :
Bonjour,

Dans le cadre d'une application, nous aimerions que lorsqu'un utilisateur
modifie une fiche, les autres utilisateurs ne puisse plus entrer en
modification sur cette meme fiche.



Le mode de fonctionnement que vous voulez mettre en oeuvre fut celui des
systèmes de fichiers Cobol dans les années 60.

Les bases ded onnées ont été une évolution naturelle de ce mode à partir
des années 80.
Or elles fonctionnent à l'inverse : aucun blocage préventif (on parle de
verrouillage pessimiste) n'est entrepris. Seul un mécanime de verrous
optimistes est mis en oeuvre.
Les GBDR modernes comme SQL Server sont capable de traiter des dizaines
de milliers d'utilisateurs simultanément.
Ce que vous voulez faire revient à utiliser votre base en mono utilisateur.
En particulier prévoir une transaction contenant de l'interaction
utilisateur (saisie, consultation....) va avoir des conséquences
catastrophiques en terme de performances.
Soit vous maintenez votre position et dans ce cas je vous conseille de
revenir aux fichiers Cobol, soit vous voulez quelque chose de moderne et
performant et dans ce cas SQL Server est bien adapté, mais il me parait
nécessaire que vous vous formiez aux concepts des bases de données
relationnelles, au langage SQL et à SQL Server en particulier.

Notez au passage que la notion de "fiche" n'existe pas dans les SGBDR.
C'est une notion purement applicative...

A +


Nous avons alors penser a mettre une transaction dans notre code au moment
du passage en modification.
La premiere operation de cette transaction est de faire un 'select' sur un
des champs afin de poser un verrou partagé et ainsi empecher qu'un verrou
exclusif soit accepté.
Cependant, pour eviter d'avoir un message d'erreur SQL Server et plutot
mettre le notre, nous aimerions interroger la base, au moment de passer en
modif.

Quelle instruction devons nous utiliser ?
Comme information, nous avons le nom de la table mais nous n'arrivons pas a
faire le lien avec sys.dm_tran_locks

Par avance merci
Franck






--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Franck
Le #11838731
Bonjour,

Je comprends tres bien vos arguments mais a contrario, si deux utilisateurs
modifient, par exemple, le meme tarif en meme temps, cela pose pb.

Ex, Si l'utilisateur B enregistre apres l'utilisateur A, alors A, editera
des factures avec les tarifs de B sans se rendent compte qu'il n'utilise
absolument pas les tarifs qu'il souhaiterait (qu'il vient pourtant de
modifier mais qui ont ete ecrase). Cela engendre des problemes de
comptabilite qui pourront etre beaucoup plus catastrophique pour
l'entreprise que des problemes de performance.

Quelle solution a cela ?
Franck



"Fred BROUARD"
Microsoft a écrit :
Bonjour,

Dans le cadre d'une application, nous aimerions que lorsqu'un utilisateur
modifie une fiche, les autres utilisateurs ne puisse plus entrer en
modification sur cette meme fiche.



Le mode de fonctionnement que vous voulez mettre en oeuvre fut celui des
systèmes de fichiers Cobol dans les années 60.

Les bases ded onnées ont été une évolution naturelle de ce mode à partir
des années 80.
Or elles fonctionnent à l'inverse : aucun blocage préventif (on parle de
verrouillage pessimiste) n'est entrepris. Seul un mécanime de verrous
optimistes est mis en oeuvre.
Les GBDR modernes comme SQL Server sont capable de traiter des dizaines de
milliers d'utilisateurs simultanément.
Ce que vous voulez faire revient à utiliser votre base en mono
utilisateur.
En particulier prévoir une transaction contenant de l'interaction
utilisateur (saisie, consultation....) va avoir des conséquences
catastrophiques en terme de performances.
Soit vous maintenez votre position et dans ce cas je vous conseille de
revenir aux fichiers Cobol, soit vous voulez quelque chose de moderne et
performant et dans ce cas SQL Server est bien adapté, mais il me parait
nécessaire que vous vous formiez aux concepts des bases de données
relationnelles, au langage SQL et à SQL Server en particulier.

Notez au passage que la notion de "fiche" n'existe pas dans les SGBDR.
C'est une notion purement applicative...

A +


Nous avons alors penser a mettre une transaction dans notre code au
moment du passage en modification.
La premiere operation de cette transaction est de faire un 'select' sur
un des champs afin de poser un verrou partagé et ainsi empecher qu'un
verrou exclusif soit accepté.
Cependant, pour eviter d'avoir un message d'erreur SQL Server et plutot
mettre le notre, nous aimerions interroger la base, au moment de passer
en modif.

Quelle instruction devons nous utiliser ?
Comme information, nous avons le nom de la table mais nous n'arrivons pas
a faire le lien avec sys.dm_tran_locks

Par avance merci
Franck




--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************


Fred BROUARD
Le #11838691
Bonsoit,

Franck a écrit :
Bonjour,

Je comprends tres bien vos arguments mais a contrario, si deux utilisateurs
modifient, par exemple, le meme tarif en meme temps, cela pose pb.



en principe non.


Ex, Si l'utilisateur B enregistre apres l'utilisateur A, alors A, editera
des factures avec les tarifs de B sans se rendent compte qu'il n'utilise
absolument pas les tarifs qu'il souhaiterait (qu'il vient pourtant de
modifier mais qui ont ete ecrase). Cela engendre des problemes de
comptabilite qui pourront etre beaucoup plus catastrophique pour
l'entreprise que des problemes de performance.



Cela dépend de la façon dont est faite la mise à jour.

> Quelle solution a cela ?

Si c'est en client lourd, vous passez vraisemblablement par un curseur.
Il y aura donc un conflit de mise à jour et l'utilisateur B recevra un
message d'erreur lui indiquant que la version de la ligne à changer et
que l'UPDATE ne peut s'effectuer.

Si c'est en client léger, alors comme il s'agit de copie statiques de
données, tout peut arriver. Si vous voulez reproduire exactement le
comportement ci dessus il vous faut par exemple implémenter une
stratégie de versionning de ligne à l'aide par exemple de GUID.





Bref, la solution n'est pas de réinventer la roue, mais de comprendre
coment fonctionne un SGBDR pour en tirer le meilleur !

A +

Franck




--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Publicité
Poster une réponse
Anonyme