Dans une table (type Access & multi-users)
comment puis-je *marquer* un enregistrement pour signaler qu'il est en cours de modification.
D'abord j'ai pensé ajouter un champ "Locked" et le mettre à True pour le *marqué* afin d'empêcher les autres utilisateurs de faire
des modifications.
Mais si le programme s'arrête anormalement (run-time error p.ex.), plus personne ne pourra modifier l'enregistrement (puisque le
champs n'a pas été remis à False).
D'accord avec Quasimodo ..... On ne doit pas bloquer un enregistrement (et encore moins un groupe d'enreg.) pendant plus de qq. secondes (cf. BEGIN TRANSACTION ci-dessous). Ne pas oublier qu'a l'échelle de l'ordinateur, le temps va a une vitesse de 10000..... .....fois plus vite que la plus rapide action humaine !
D'ou mon explication assez détaillée sur ce qu'on appelle l'utilisation du COMMIT a 2 phases .....
Cela se retrouve donc dans un probleme d'analyse, a vérifier par les contraintes d'exploitation !
@+
"Quasimodo" a écrit dans le message de news:
YannX was thinking very hard : > Non, je n'etais absolument pas sur de la vexation .......no problemo, > juste que je cherchais a etre sur de bien comprendre ! > > Alors, au-dela du blocage implicite automatique de Jet (au niveau page, > dis-tu ? cf.Oracle ;-) > je maintiens que la bonne technique de tout SGBD qui se respecte, > pour bloquer un-des enregistrments inter-liés en modification, > est d'encapsuler l'ensemble des opérations SELECT.......... jusqu'aux
UPDATE
> dans un BEGIN TRANSACTION ............ COMMIT .......or ROLLBACK > (sous-entendu, l'enregistrement maitre, et tous les enregistrements
reliés).
> (en cas de plantage-blocage....il est du ressort du SGBD de fermer par > Rollback... > > Mais pour te donner exactement la syntaxe a utiliser, > je ne me suis pas encore penché sur le problème en Access/VB pour te > repondre comme cela! > > Déjà, en VB6, mais lequel : en DAO ou en ADO ? > JET natif ou SQL Serveur / MSDE ? > > @+ > Y > > PS : comme le blocage (ici tu veux le faire au niveau du Form_Load()
peut
> durer "longtemps" > les vieilles techniques de SGBD traditionnelles consistaient à
faire
> une copie-buffer sans blocage, > puis, au moment de la mise a jour-écriture, a enchainer dans une > opération "transaction" : > - BEGIN TRANSACTION > - relire les enreg. déjà mémorisés en buffer, > - comparer avec le buffer copié, > - si pas de modif, modifier TOUS les enregistrements en mémoire > avec ré-écriture sous controle du SGBD, > - si pas d'erreur END TRANSACTION = COMMIT de validation > sinon ROLLBACK = on n'a pas enregistré les modifications > car un autre user est venu entre-temps modifier les données > (alternative selon l'application ! appliquer les modifs, > sur la version relue juste avant ! > Le tout bien sur dans une seule procedure non-interruptible > par un queconque evenement utilisateur bien sur ! > Un peu lourd, oui, surout que je n'ai pas vue de belles instructions > sachant gérer tout un enregistrement en Stream (comme une zone binaire) > Mais c'est le principe garanti !!!!!!! > > > "Pascal B." a écrit dans le message de > news: >> Ne te vexe pas ... >> >> Je cherche *simplement* une METHODE SURE qui me permet >> d'empêcher un utilisateur de modifier quelque chose qui >> est DEJA EN TRAIN d'être modifié par un autre utilisateur. >> >> Exemple: >> L'utilisateur "A" double-clique sur un nom de client dans une liste
pour
>> modifier ses données. Une Form s'ouvrira donc avec toutes ses
coordonées.
>> Tant que l'utilisateur "A" n'a pas fermé cette Form, la fiche de ce
client
>> doit être bloqué de telle sorte que l'utilisateur "B" (sur un autre
poste)
>> ne puisse aussi modifié cette même fiche. >> >> Cordialement, >> Pascal B. >> >> "YannX" wrote in message >> news: >>> Désolé, je n'ai donc pas compris l'objectif précis ! >>> Je viens pourtant de relire tout le fil ! >>> ???????
re, sorry j'insiste à moins que je n'aie pas compris du tout et alors je m'en excuse. Il est inutile et surtout mauvais de concevoir une application qui bloque les infos (la fiche, les records, ...) que quelqu'un est occupé à consulter. Une personne ne reste pas x heures à modifier une fiche client, par contre elle peut rester quelques temps (voir heures suivant les cas) devant celle-ci et après la modifier l'espace de quelques secondes, voir minutes si vous avez un réseau hyper lent(une transaction ou un update sans transaction ne dure pas plus de x secondes). Les autres users du système d'information sont susceptibles de vouloir la consulter ou la mettre à jour et c'est normal (cf. les systèmes critiques pour les finances par exemple). Rien n'empêche (cf.: adox, ado, voir même le dao et aussi peut être jro) d'être avertis lors de tout modification d'une fiche client (enregistrement) par un autre utilisateur et ceci pendant que l'on est en cour de consultation et de faire un refresh de celle-ci, pour avoir les données ajour. Aussi, concevoir un système multi-users supportant une charge importante, permettant de gérer plus efficacement le locking et proposant des système de triggers ou autres, voir des agents, passe par l'utilisation de vrais sgbdr (tel que MS Sql server, oracle, ...). Ce qui suit ne répond peut être pas directement à votre situation actuelle, mais on ne sait jamais. Je me lance peut être dans un débat mais bon, je vous propose plutôt de passer dans un modèle n-tiers (si c'est encore possible, mais on ne change pas en cour de développement une analyse, quoi que pour la méthode xp cela pourrai se faire), qui lui vous permettra de gérer nettement plus efficacement les problèmes récurent de gestion des users (qui est connecté, à quoi, depuis quand, ...), de portabilité entre sgbdr, d'ajout de fonctionnalités, ... Je pense que le problème que vous pauser est typiquement un problème de couche software, ce n'est pas le sgbdr qui doit permettre cette fonctionnalité. Celui-ci à pour bute de garantir la sauvegarde de vos données, rapidement, sûrement, en mode mono ou multiusers, sa restitution tel qu'enregistré, gérer les accès concurrents, les locking ... et cela de sa propre manière (comment à la limite on s'en f...). Bon j'espère vous avoir un petit peux aider, au cas ou :')
@+Quaz
-- This is an automatic signature of MesNews. Site : http://mesnews.no-ip.com
D'accord avec Quasimodo .....
On ne doit pas bloquer un enregistrement (et encore moins un groupe
d'enreg.)
pendant plus de qq. secondes (cf. BEGIN TRANSACTION ci-dessous).
Ne pas oublier qu'a l'échelle de l'ordinateur, le temps va a une vitesse de
10000.....
.....fois plus vite que la plus rapide action humaine !
D'ou mon explication assez détaillée sur ce qu'on appelle
l'utilisation du COMMIT a 2 phases .....
Cela se retrouve donc dans un probleme d'analyse,
a vérifier par les contraintes d'exploitation !
@+
"Quasimodo" <wild_riki.@yahoo.fr> a écrit dans le message de
news:mn.30717d4b43183702.18602@yahoo.fr...
YannX was thinking very hard :
> Non, je n'etais absolument pas sur de la vexation .......no problemo,
> juste que je cherchais a etre sur de bien comprendre !
>
> Alors, au-dela du blocage implicite automatique de Jet (au niveau page,
> dis-tu ? cf.Oracle ;-)
> je maintiens que la bonne technique de tout SGBD qui se respecte,
> pour bloquer un-des enregistrments inter-liés en modification,
> est d'encapsuler l'ensemble des opérations SELECT.......... jusqu'aux
UPDATE
> dans un BEGIN TRANSACTION ............ COMMIT .......or ROLLBACK
> (sous-entendu, l'enregistrement maitre, et tous les enregistrements
reliés).
> (en cas de plantage-blocage....il est du ressort du SGBD de fermer par
> Rollback...
>
> Mais pour te donner exactement la syntaxe a utiliser,
> je ne me suis pas encore penché sur le problème en Access/VB pour te
> repondre comme cela!
>
> Déjà, en VB6, mais lequel : en DAO ou en ADO ?
> JET natif ou SQL Serveur / MSDE ?
>
> @+
> Y
>
> PS : comme le blocage (ici tu veux le faire au niveau du Form_Load()
peut
> durer "longtemps"
> les vieilles techniques de SGBD traditionnelles consistaient à
faire
> une copie-buffer sans blocage,
> puis, au moment de la mise a jour-écriture, a enchainer dans une
> opération "transaction" :
> - BEGIN TRANSACTION
> - relire les enreg. déjà mémorisés en buffer,
> - comparer avec le buffer copié,
> - si pas de modif, modifier TOUS les enregistrements en mémoire
> avec ré-écriture sous controle du SGBD,
> - si pas d'erreur END TRANSACTION = COMMIT de validation
> sinon ROLLBACK = on n'a pas enregistré les modifications
> car un autre user est venu entre-temps modifier les données
> (alternative selon l'application ! appliquer les modifs,
> sur la version relue juste avant !
> Le tout bien sur dans une seule procedure non-interruptible
> par un queconque evenement utilisateur bien sur !
> Un peu lourd, oui, surout que je n'ai pas vue de belles instructions
> sachant gérer tout un enregistrement en Stream (comme une zone binaire)
> Mais c'est le principe garanti !!!!!!!
>
>
> "Pascal B." <Pascbr@hotmail_ANTISPASM_.com> a écrit dans le message de
> news:eHjgGrzwEHA.1192@tk2msftngp13.phx.gbl...
>> Ne te vexe pas ...
>>
>> Je cherche *simplement* une METHODE SURE qui me permet
>> d'empêcher un utilisateur de modifier quelque chose qui
>> est DEJA EN TRAIN d'être modifié par un autre utilisateur.
>>
>> Exemple:
>> L'utilisateur "A" double-clique sur un nom de client dans une liste
pour
>> modifier ses données. Une Form s'ouvrira donc avec toutes ses
coordonées.
>> Tant que l'utilisateur "A" n'a pas fermé cette Form, la fiche de ce
client
>> doit être bloqué de telle sorte que l'utilisateur "B" (sur un autre
poste)
>> ne puisse aussi modifié cette même fiche.
>>
>> Cordialement,
>> Pascal B.
>>
>> "YannX" <ydx_nospam@yahoo.fr> wrote in message
>> news:O0VwhYzwEHA.3292@TK2MSFTNGP15.phx.gbl...
>>> Désolé, je n'ai donc pas compris l'objectif précis !
>>> Je viens pourtant de relire tout le fil !
>>> ???????
re,
sorry j'insiste à moins que je n'aie pas compris du tout et alors je
m'en excuse.
Il est inutile et surtout mauvais de concevoir une application qui
bloque les infos (la fiche, les records, ...) que quelqu'un est occupé
à consulter.
Une personne ne reste pas x heures à modifier une fiche client, par
contre elle peut rester quelques temps (voir heures suivant les cas)
devant celle-ci et après la modifier l'espace de quelques secondes,
voir minutes si vous avez un réseau hyper lent(une transaction ou un
update sans transaction ne dure pas plus de x secondes). Les autres
users du système d'information sont susceptibles de vouloir la
consulter ou la mettre à jour et c'est normal (cf. les systèmes
critiques pour les finances par exemple).
Rien n'empêche (cf.: adox, ado, voir même le dao et aussi peut être
jro) d'être avertis lors de tout modification d'une fiche client
(enregistrement) par un autre utilisateur et ceci pendant que l'on est
en cour de consultation et de faire un refresh de celle-ci, pour avoir
les données ajour.
Aussi, concevoir un système multi-users supportant une charge
importante, permettant de gérer plus efficacement le locking et
proposant des système de triggers ou autres, voir des agents, passe par
l'utilisation de vrais sgbdr (tel que MS Sql server, oracle, ...).
Ce qui suit ne répond peut être pas directement à votre situation
actuelle, mais on ne sait jamais. Je me lance peut être dans un débat
mais bon, je vous propose plutôt de passer dans un modèle n-tiers (si
c'est encore possible, mais on ne change pas en cour de développement
une analyse, quoi que pour la méthode xp cela pourrai se faire), qui
lui vous permettra de gérer nettement plus efficacement les problèmes
récurent de gestion des users (qui est connecté, à quoi, depuis quand,
...), de portabilité entre sgbdr, d'ajout de fonctionnalités, ... Je
pense que le problème que vous pauser est typiquement un problème de
couche software, ce n'est pas le sgbdr qui doit permettre cette
fonctionnalité. Celui-ci à pour bute de garantir la sauvegarde de vos
données, rapidement, sûrement, en mode mono ou multiusers, sa
restitution tel qu'enregistré, gérer les accès concurrents, les locking
... et cela de sa propre manière (comment à la limite on s'en f...).
Bon j'espère vous avoir un petit peux aider, au cas ou :')
@+Quaz
--
This is an automatic signature of MesNews.
Site : http://mesnews.no-ip.com
D'accord avec Quasimodo ..... On ne doit pas bloquer un enregistrement (et encore moins un groupe d'enreg.) pendant plus de qq. secondes (cf. BEGIN TRANSACTION ci-dessous). Ne pas oublier qu'a l'échelle de l'ordinateur, le temps va a une vitesse de 10000..... .....fois plus vite que la plus rapide action humaine !
D'ou mon explication assez détaillée sur ce qu'on appelle l'utilisation du COMMIT a 2 phases .....
Cela se retrouve donc dans un probleme d'analyse, a vérifier par les contraintes d'exploitation !
@+
"Quasimodo" a écrit dans le message de news:
YannX was thinking very hard : > Non, je n'etais absolument pas sur de la vexation .......no problemo, > juste que je cherchais a etre sur de bien comprendre ! > > Alors, au-dela du blocage implicite automatique de Jet (au niveau page, > dis-tu ? cf.Oracle ;-) > je maintiens que la bonne technique de tout SGBD qui se respecte, > pour bloquer un-des enregistrments inter-liés en modification, > est d'encapsuler l'ensemble des opérations SELECT.......... jusqu'aux
UPDATE
> dans un BEGIN TRANSACTION ............ COMMIT .......or ROLLBACK > (sous-entendu, l'enregistrement maitre, et tous les enregistrements
reliés).
> (en cas de plantage-blocage....il est du ressort du SGBD de fermer par > Rollback... > > Mais pour te donner exactement la syntaxe a utiliser, > je ne me suis pas encore penché sur le problème en Access/VB pour te > repondre comme cela! > > Déjà, en VB6, mais lequel : en DAO ou en ADO ? > JET natif ou SQL Serveur / MSDE ? > > @+ > Y > > PS : comme le blocage (ici tu veux le faire au niveau du Form_Load()
peut
> durer "longtemps" > les vieilles techniques de SGBD traditionnelles consistaient à
faire
> une copie-buffer sans blocage, > puis, au moment de la mise a jour-écriture, a enchainer dans une > opération "transaction" : > - BEGIN TRANSACTION > - relire les enreg. déjà mémorisés en buffer, > - comparer avec le buffer copié, > - si pas de modif, modifier TOUS les enregistrements en mémoire > avec ré-écriture sous controle du SGBD, > - si pas d'erreur END TRANSACTION = COMMIT de validation > sinon ROLLBACK = on n'a pas enregistré les modifications > car un autre user est venu entre-temps modifier les données > (alternative selon l'application ! appliquer les modifs, > sur la version relue juste avant ! > Le tout bien sur dans une seule procedure non-interruptible > par un queconque evenement utilisateur bien sur ! > Un peu lourd, oui, surout que je n'ai pas vue de belles instructions > sachant gérer tout un enregistrement en Stream (comme une zone binaire) > Mais c'est le principe garanti !!!!!!! > > > "Pascal B." a écrit dans le message de > news: >> Ne te vexe pas ... >> >> Je cherche *simplement* une METHODE SURE qui me permet >> d'empêcher un utilisateur de modifier quelque chose qui >> est DEJA EN TRAIN d'être modifié par un autre utilisateur. >> >> Exemple: >> L'utilisateur "A" double-clique sur un nom de client dans une liste
pour
>> modifier ses données. Une Form s'ouvrira donc avec toutes ses
coordonées.
>> Tant que l'utilisateur "A" n'a pas fermé cette Form, la fiche de ce
client
>> doit être bloqué de telle sorte que l'utilisateur "B" (sur un autre
poste)
>> ne puisse aussi modifié cette même fiche. >> >> Cordialement, >> Pascal B. >> >> "YannX" wrote in message >> news: >>> Désolé, je n'ai donc pas compris l'objectif précis ! >>> Je viens pourtant de relire tout le fil ! >>> ???????
re, sorry j'insiste à moins que je n'aie pas compris du tout et alors je m'en excuse. Il est inutile et surtout mauvais de concevoir une application qui bloque les infos (la fiche, les records, ...) que quelqu'un est occupé à consulter. Une personne ne reste pas x heures à modifier une fiche client, par contre elle peut rester quelques temps (voir heures suivant les cas) devant celle-ci et après la modifier l'espace de quelques secondes, voir minutes si vous avez un réseau hyper lent(une transaction ou un update sans transaction ne dure pas plus de x secondes). Les autres users du système d'information sont susceptibles de vouloir la consulter ou la mettre à jour et c'est normal (cf. les systèmes critiques pour les finances par exemple). Rien n'empêche (cf.: adox, ado, voir même le dao et aussi peut être jro) d'être avertis lors de tout modification d'une fiche client (enregistrement) par un autre utilisateur et ceci pendant que l'on est en cour de consultation et de faire un refresh de celle-ci, pour avoir les données ajour. Aussi, concevoir un système multi-users supportant une charge importante, permettant de gérer plus efficacement le locking et proposant des système de triggers ou autres, voir des agents, passe par l'utilisation de vrais sgbdr (tel que MS Sql server, oracle, ...). Ce qui suit ne répond peut être pas directement à votre situation actuelle, mais on ne sait jamais. Je me lance peut être dans un débat mais bon, je vous propose plutôt de passer dans un modèle n-tiers (si c'est encore possible, mais on ne change pas en cour de développement une analyse, quoi que pour la méthode xp cela pourrai se faire), qui lui vous permettra de gérer nettement plus efficacement les problèmes récurent de gestion des users (qui est connecté, à quoi, depuis quand, ...), de portabilité entre sgbdr, d'ajout de fonctionnalités, ... Je pense que le problème que vous pauser est typiquement un problème de couche software, ce n'est pas le sgbdr qui doit permettre cette fonctionnalité. Celui-ci à pour bute de garantir la sauvegarde de vos données, rapidement, sûrement, en mode mono ou multiusers, sa restitution tel qu'enregistré, gérer les accès concurrents, les locking ... et cela de sa propre manière (comment à la limite on s'en f...). Bon j'espère vous avoir un petit peux aider, au cas ou :')
@+Quaz
-- This is an automatic signature of MesNews. Site : http://mesnews.no-ip.com
