Bonjour,

Je recherche des informations sur la façon de gérer le lock sur un
enregistrement (une ligne) d'une table SQL Server. Je travaille en
effet sur une application VBA client/serveur où je voudrais empêcher
que deux utilisateurs puissent modifier simultanément les mêmes
données.

Quelles instructions faut-il utiliser, comment gère t-on les locks (au
niveau session ?) et comment se prémunir contre le blocage
d'enregistrements en cas de "plantage" de l'application (dé-locker
automatiquement les enregistrements lockés par un utilisateur ?)

Merci de vos conseils.

--
QUI SE RESSEMBLE N'EST JAMAIS PERDU (Proverbe)

ByB a écrit :
> Bonjour,
>
> Je recherche des informations sur la façon de gérer le lock sur un
> enregistrement (une ligne) d'une table SQL Server. Je travaille en effet
> sur une application VBA client/serveur où je voudrais empêcher que deux
> utilisateurs puissent modifier simultanément les mêmes données.

Cela ne sera jamais possible. En effet SQL Server est un SGBDR est la
vérouillage est automatique !

>
> Quelles instructions faut-il utiliser, comment gère t-on les locks (au
> niveau session ?) et comment se prémunir contre le blocage
> d'enregistrements en cas de "plantage" de l'application (dé-locker
> automatiquement les enregistrements lockés par un utilisateur ?)

Si vous voulez faire du verrouillage manuel vous risquez des
performances lamentables voir des deadlocks. Laissez faire le système....

Que voulez-vous faire exactement ?

A +

>
> Merci de vos conseils.
>


--
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 ***********************

Comme souligne Fred BROUARD je vous conseil fortement de ne pas utiliser
explicitement les locks (style WITH(ROWLOCK, XLOCK)....) et de laisser SQL
Server gère le type et le niveau de lock nécessaire.



Par contre vous pouvez le faire coté BD et application



Cote BD :

Créer une colonne : VersionNo par exemple et un trigger d'Update qui vérifie
que le No de version envoyé par le user correspond a la version courante si
différent, raise un message d'erreur que l'enregistrement est déjà modifié,
si identique le trigger augmente le No de version de 1.



Coté Application : l'application doit fournir lors de l'update le No de
version original



Exemple :

Le user1 extrait l'enregistrement x dont le No de version est 3

Le user2 extrait l'enregistrement x dont le No de version est 3



Le user1 fait les modifications nécessaires et submit les modifications avec
le No de version 3, le trigger d'update trouve que le No de version submité
par le user 1 correspond a la valeur dans la BD, il accepte la transaction
est augmente le no de version qui passe a 4.



Le user2 fait les modifications nécessaires et submit les modifications avec
le No de version 3, le trigger d'update trouve que le No de version submité
par le user 2 est différent a la valeur dans la BD (4) et raise un message
d'erreur.



Vous pouvez aussi utilisé une colonne de type timestamp, cherche dans
l'archive des news vous trouverez certainement des exemples



Merci

Bouarroudj Mohamed
www.sqldbtools.com


"Fred BROUARD" <brouardf@club-internet.fr> wrote in message
news:eH7lY5n0HHA.5980@TK2MSFTNGP04.phx.gbl...
> ByB a écrit :
>> Bonjour,
>>
>> Je recherche des informations sur la façon de gérer le lock sur un
>> enregistrement (une ligne) d'une table SQL Server. Je travaille en effet
>> sur une application VBA client/serveur où je voudrais empêcher que deux
>> utilisateurs puissent modifier simultanément les mêmes données.
>
> Cela ne sera jamais possible. En effet SQL Server est un SGBDR est la
> vérouillage est automatique !
>
>>
>> Quelles instructions faut-il utiliser, comment gère t-on les locks (au
>> niveau session ?) et comment se prémunir contre le blocage
>> d'enregistrements en cas de "plantage" de l'application (dé-locker
>> automatiquement les enregistrements lockés par un utilisateur ?)
>
> Si vous voulez faire du verrouillage manuel vous risquez des performances
> lamentables voir des deadlocks. Laissez faire le système....
>
> Que voulez-vous faire exactement ?
>
> A +
>
>>
>> Merci de vos conseils.
>>
>
>
> --
> 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 ***********************

Qui d'autre que SM aurait pu nous affirmer que
> Comme souligne Fred BROUARD je vous conseil fortement de ne pas utiliser
> explicitement les locks (style WITH(ROWLOCK, XLOCK)....) et de laisser SQL
> Server gère le type et le niveau de lock nécessaire.



> Par contre vous pouvez le faire coté BD et application



> Cote BD :

> Créer une colonne : VersionNo par exemple et un trigger d'Update qui vérifie
> que le No de version envoyé par le user correspond a la version courante si
> différent, raise un message d'erreur que l'enregistrement est déjà modifié,
> si identique le trigger augmente le No de version de 1.



> Coté Application : l'application doit fournir lors de l'update le No de
> version original



> Exemple :

> Le user1 extrait l'enregistrement x dont le No de version est 3

> Le user2 extrait l'enregistrement x dont le No de version est 3



> Le user1 fait les modifications nécessaires et submit les modifications avec
> le No de version 3, le trigger d'update trouve que le No de version submité
> par le user 1 correspond a la valeur dans la BD, il accepte la transaction
> est augmente le no de version qui passe a 4.



> Le user2 fait les modifications nécessaires et submit les modifications avec
> le No de version 3, le trigger d'update trouve que le No de version submité
> par le user 2 est différent a la valeur dans la BD (4) et raise un message
> d'erreur.



> Vous pouvez aussi utilisé une colonne de type timestamp, cherche dans
> l'archive des news vous trouverez certainement des exemples



> Merci

> Bouarroudj Mohamed
> www.sqldbtools.com


> "Fred BROUARD" <brouardf@club-internet.fr> wrote in message
> news:eH7lY5n0HHA.5980@TK2MSFTNGP04.phx.gbl...
>> ByB a écrit :
>>> Bonjour,
>>>
>>> Je recherche des informations sur la façon de gérer le lock sur un
>>> enregistrement (une ligne) d'une table SQL Server. Je travaille en effet
>>> sur une application VBA client/serveur où je voudrais empêcher que deux
>>> utilisateurs puissent modifier simultanément les mêmes données.
>>
>> Cela ne sera jamais possible. En effet SQL Server est un SGBDR est la
>> vérouillage est automatique !
>>
>>>
>>> Quelles instructions faut-il utiliser, comment gère t-on les locks (au
>>> niveau session ?) et comment se prémunir contre le blocage
>>> d'enregistrements en cas de "plantage" de l'application (dé-locker
>>> automatiquement les enregistrements lockés par un utilisateur ?)
>>
>> Si vous voulez faire du verrouillage manuel vous risquez des performances
>> lamentables voir des deadlocks. Laissez faire le système....
>>
>> Que voulez-vous faire exactement ?
>>
>> A +
>>
>>>
>>> Merci de vos conseils.
>>>
>>
>>
>> -- 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 ***********************

Merci de vos conseils.

--
LE VECU PONCTUE LES EFFETS ANALYTIQUES DU DISPOSITIF

Salut ByB,
Je rejoins ces messieurs sur la piste de la gestion de verrous par le SGBDR
à privilégier. Si tes transactions ne sont pas "critiques", tu peux toujours
passer ton niveau d'isolation de transactions de tes sessions à READ
UNCOMMITTED. Tu peux également paramétrer un Request TimeOut au niveau de
l'instance, mais bon..

Par ailleurs, puisque tu attaques ta base SQL en VBA, le fais-tu par
RecordSet en ADO ou par un DataSet en ADO.net ? SM propose l'ajout d'une
colonne: pourquoi pas mais je trouve cette approche fastidieuse et tu risques
vite d'arriver à un montage d'usine à gaz. A toi de juger... Néanmoins il est
vrai qu'au niveau applicatif tu peux agir sur certains points, comme
l'approche optimistic / pessimistic en ADO ou d'autres choses...

Fred.M.

"ByB" a écrit :

> Qui d'autre que SM aurait pu nous affirmer que
> > Comme souligne Fred BROUARD je vous conseil fortement de ne pas utiliser
> > explicitement les locks (style WITH(ROWLOCK, XLOCK)....) et de laisser SQL
> > Server gère le type et le niveau de lock nécessaire.
>
>
>
> > Par contre vous pouvez le faire coté BD et application
>
>
>
> > Cote BD :
>
> > Créer une colonne : VersionNo par exemple et un trigger d'Update qui vérifie
> > que le No de version envoyé par le user correspond a la version courante si
> > différent, raise un message d'erreur que l'enregistrement est déjà modifié,
> > si identique le trigger augmente le No de version de 1.
>
>
>
> > Coté Application : l'application doit fournir lors de l'update le No de
> > version original
>
>
>
> > Exemple :
>
> > Le user1 extrait l'enregistrement x dont le No de version est 3
>
> > Le user2 extrait l'enregistrement x dont le No de version est 3
>
>
>
> > Le user1 fait les modifications nécessaires et submit les modifications avec
> > le No de version 3, le trigger d'update trouve que le No de version submité
> > par le user 1 correspond a la valeur dans la BD, il accepte la transaction
> > est augmente le no de version qui passe a 4.
>
>
>
> > Le user2 fait les modifications nécessaires et submit les modifications avec
> > le No de version 3, le trigger d'update trouve que le No de version submité
> > par le user 2 est différent a la valeur dans la BD (4) et raise un message
> > d'erreur.
>
>
>
> > Vous pouvez aussi utilisé une colonne de type timestamp, cherche dans
> > l'archive des news vous trouverez certainement des exemples
>
>
>
> > Merci
>
> > Bouarroudj Mohamed
> > www.sqldbtools.com
>
>
> > "Fred BROUARD" <brouardf@club-internet.fr> wrote in message
> > news:eH7lY5n0HHA.5980@TK2MSFTNGP04.phx.gbl...
> >> ByB a écrit :
> >>> Bonjour,
> >>>
> >>> Je recherche des informations sur la façon de gérer le lock sur un
> >>> enregistrement (une ligne) d'une table SQL Server. Je travaille en effet
> >>> sur une application VBA client/serveur où je voudrais empêcher que deux
> >>> utilisateurs puissent modifier simultanément les mêmes données.
> >>
> >> Cela ne sera jamais possible. En effet SQL Server est un SGBDR est la
> >> vérouillage est automatique !
> >>
> >>>
> >>> Quelles instructions faut-il utiliser, comment gère t-on les locks (au
> >>> niveau session ?) et comment se prémunir contre le blocage
> >>> d'enregistrements en cas de "plantage" de l'application (dé-locker
> >>> automatiquement les enregistrements lockés par un utilisateur ?)
> >>
> >> Si vous voulez faire du verrouillage manuel vous risquez des performances
> >> lamentables voir des deadlocks. Laissez faire le système....
> >>
> >> Que voulez-vous faire exactement ?
> >>
> >> A +
> >>
> >>>
> >>> Merci de vos conseils.
> >>>
> >>
> >>
> >> -- 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 ***********************
>
> Merci de vos conseils.
>
> --
> LE VECU PONCTUE LES EFFETS ANALYTIQUES DU DISPOSITIF
>
>
>