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.
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.
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.
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 ***********************
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 ***********************
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" wrote in message
news: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 ***********************
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" wrote in message
news: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" wrote in message
> news:
>> 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
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
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" wrote in message
> news:
>> 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