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
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
bruno reiter
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" wrote in message 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
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" <FJplmsa@hotmail.com> wrote in message
news:%23X%23ddXBeHHA.4752@TK2MSFTNGP02.phx.gbl...
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
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" wrote in message 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
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 ***********************
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 ***********************
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
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" a écrit dans le message de news:
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 ***********************
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" <brouardf@club-internet.fr> a écrit dans le message de news:
eFg8xrzeHHA.1312@TK2MSFTNGP03.phx.gbl...
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 ***********************
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" a écrit dans le message de news:
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
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 ***********************
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 ***********************
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 ***********************
