Ma question est peut-être surprenante, je sais que Sql server gère les
blocages lors des mémorisations tout seul mais je vous expose le souci
:
Dans le cadre d'utilisation multi-postes, une même fiche peut-être
appelée par plusieurs postes. Je souhaite afficher un message ou
interdire la modification d'une information si celle-ci est déjà
affichée et en cours de modification sur un autre poste.
Par exemple, la fiche du client "Toto" est en cours de modification sur
un poste X. Le poste Y veut lui aussi modifier cette fiche. Je désire
bloquer la fiche sur le poste X et lors de son appel sur le poste Y
afficher "le client est en cours de modification sur un autre poste".
Quelles instructions Sql permettent de bloquer, vérifier le blocage et
débloquer une ligne ?
Mon but n'est pas d'avertir le 2ème utilisateur, après qu'il ait saisi
ses modifications, que la fiche a déjà été modifiée par quelqu'un
d'autres pendant ce temps. Ca je pourrais le faire en testant des
colonnes dans lesquelles je mémoriserais les dates et heures des
dernières modifications.
Je pourrais aussi rajouter une colonne dans les tables concernées pour
un mettre le code de l'utilisateur concerné et l'enlever à la fin de sa
modification, mais en cas de plantage, la valeur reste dans la colonne
et la ligne est toujours considérée comme bloquée.
Voila, je ne sais pas si j'ai été très clair dans ma demande ...
Merci pour cette réponse. Effectivement un processus qui tourne continuellement et se charge de libérer les éléments restés "bloqués" trop longtemps est intéressant.
dans ce cas inutile de prendre un SGDR client serveur. Préférez un SGBDR fichier comme paradox... (je vais faire plaisir à Come....) Cela sera beaucoup plus facile à implémenter....
Salut
Mais dans le cas d'une appli web on est rarement en mode connecté sur la base non ?. S'appuyer sur les lock de la base de données ne me semble pas jouable dans ce contexte. Pour une transaction très courte comme incrémenter un compteur d'accord mais au delà ? Comment gérer la déconnexion propre de la base et/ou la fin de transaction quand l'utilisateur peut simplement fermer son navigateur ou laisser sa session expirer ? De toute façon que le lock soit géré par l'appli ou par la base il va bien falloir un processus capable de nettoyer ce qui doit l'être !
Sinon pas besoin de Paradox, aujourd'hui les principaux SGBD savent faire du lock pessimiste me semble-t-il.
non jutement il ne font pas de verrouillage pessimiste pour des raisons de performance. Mais on peut toujours l'implémenter de manière simple.
Par contre on peut faire du snapshot... C'est souvent plus intéressant.
A +
-- 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.sqlspot.com *************************
Côme de Christen a écrit :
"Fred BROUARD" <brouardf@club-internet.fr> a écrit dans le message de news:
OAhYJIdPIHA.6036@TK2MSFTNGP03.phx.gbl...
Juanito a écrit :
Merci pour cette réponse. Effectivement un processus qui tourne
continuellement et se charge de libérer les éléments restés "bloqués" trop
longtemps est intéressant.
dans ce cas inutile de prendre un SGDR client serveur. Préférez un SGBDR
fichier comme paradox... (je vais faire plaisir à Come....) Cela sera beaucoup
plus facile à implémenter....
Salut
Mais dans le cas d'une appli web on est rarement en mode connecté sur la base
non ?. S'appuyer sur les lock de la base de données ne me semble pas jouable
dans ce contexte. Pour une transaction très courte comme incrémenter un compteur
d'accord mais au delà ? Comment gérer la déconnexion propre de la base et/ou la
fin de transaction quand l'utilisateur peut simplement fermer son navigateur ou
laisser sa session expirer ?
De toute façon que le lock soit géré par l'appli ou par la base il va bien
falloir un processus capable de nettoyer ce qui doit l'être !
Sinon pas besoin de Paradox, aujourd'hui les principaux SGBD savent faire du
lock pessimiste me semble-t-il.
non jutement il ne font pas de verrouillage pessimiste pour des raisons
de performance. Mais on peut toujours l'implémenter de manière simple.
Par contre on peut faire du snapshot... C'est souvent plus intéressant.
A +
--
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.sqlspot.com *************************
Merci pour cette réponse. Effectivement un processus qui tourne continuellement et se charge de libérer les éléments restés "bloqués" trop longtemps est intéressant.
dans ce cas inutile de prendre un SGDR client serveur. Préférez un SGBDR fichier comme paradox... (je vais faire plaisir à Come....) Cela sera beaucoup plus facile à implémenter....
Salut
Mais dans le cas d'une appli web on est rarement en mode connecté sur la base non ?. S'appuyer sur les lock de la base de données ne me semble pas jouable dans ce contexte. Pour une transaction très courte comme incrémenter un compteur d'accord mais au delà ? Comment gérer la déconnexion propre de la base et/ou la fin de transaction quand l'utilisateur peut simplement fermer son navigateur ou laisser sa session expirer ? De toute façon que le lock soit géré par l'appli ou par la base il va bien falloir un processus capable de nettoyer ce qui doit l'être !
Sinon pas besoin de Paradox, aujourd'hui les principaux SGBD savent faire du lock pessimiste me semble-t-il.
non jutement il ne font pas de verrouillage pessimiste pour des raisons de performance. Mais on peut toujours l'implémenter de manière simple.
Par contre on peut faire du snapshot... C'est souvent plus intéressant.
A +
-- 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.sqlspot.com *************************
Côme de Christen
"Fred BROUARD" a écrit dans le message de news: %
Côme de Christen a écrit :
Sinon pas besoin de Paradox, aujourd'hui les principaux SGBD savent faire du lock pessimiste me semble-t-il.
non jutement il ne font pas de verrouillage pessimiste pour des raisons de performance. Mais on peut toujours l'implémenter de manière simple.
Par contre on peut faire du snapshot... C'est souvent plus intéressant.
Si si je t'assure les principaux SGBD savent faire du lock record
Oracle , PostgreSQL, MySQL (InnoDb) : SELECT.... FOR UPDATE Firebird (>=1.5) : SELECT ... [FOR UPDATE [OF...]] WITH LOCK
etc...
Qu'ils ne le fasse pas par défaut certes, mais c'est bien possible facilement Certe le snapshot est possible mais je ne vois pas bien en quoi cela va aider dans la situation
"Fred BROUARD" <brouardf@club-internet.fr> a écrit dans le message de news:
%23ZFWA4xPIHA.1184@TK2MSFTNGP04.phx.gbl...
Côme de Christen a écrit :
Sinon pas besoin de Paradox, aujourd'hui les principaux SGBD savent faire du
lock pessimiste me semble-t-il.
non jutement il ne font pas de verrouillage pessimiste pour des raisons de
performance. Mais on peut toujours l'implémenter de manière simple.
Par contre on peut faire du snapshot... C'est souvent plus intéressant.
Si si je t'assure les principaux SGBD savent faire du lock record
Oracle , PostgreSQL, MySQL (InnoDb) : SELECT.... FOR UPDATE
Firebird (>=1.5) : SELECT ... [FOR UPDATE [OF...]] WITH LOCK
etc...
Qu'ils ne le fasse pas par défaut certes, mais c'est bien possible facilement
Certe le snapshot est possible mais je ne vois pas bien en quoi cela va aider
dans la situation
Sinon pas besoin de Paradox, aujourd'hui les principaux SGBD savent faire du lock pessimiste me semble-t-il.
non jutement il ne font pas de verrouillage pessimiste pour des raisons de performance. Mais on peut toujours l'implémenter de manière simple.
Par contre on peut faire du snapshot... C'est souvent plus intéressant.
Si si je t'assure les principaux SGBD savent faire du lock record
Oracle , PostgreSQL, MySQL (InnoDb) : SELECT.... FOR UPDATE Firebird (>=1.5) : SELECT ... [FOR UPDATE [OF...]] WITH LOCK
etc...
Qu'ils ne le fasse pas par défaut certes, mais c'est bien possible facilement Certe le snapshot est possible mais je ne vois pas bien en quoi cela va aider dans la situation
