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