Eviter plusieurs accés simultanés à un recordset.

John a écrit, le 12/09/2012 18:44 :

Aprés qu'un utilisateur ait saisi ses données dans un
formulaire, ces données sont enregistrées dans une table
via un recordset (rs) ouvert par une requète SQL.
En gros ca se présente comme ca :

rs.Edit
rs( truc ) = valeur
' etc ...
rs.Update

Tout cela marche trés bien avec un seul utilisateur, mais pas
quand plusieurs utilisateurs mettent à jour en même temps.

Dans ce cas, quelles sont les méthodes à utiliser pour
éviter deux (ou plus) accès simultanés à un recordset ?

Bonjour,

Première chose, il va falloir regarder dans les options d'Access, parce
que par défaut, une fois qu'une base est ouverte sur une machine, aucun e
autre ne peut y avoir accès, donc il faut regarder les propriétés
concernées par le verrouillage. Je n'ai pas l'intitulé exact en têt e,
désolé, mais une option permet l'accès concurrentiel depuis plusieu rs
postes. Mais peut-être as-tu déjà vu cela si tu as pu essayer les a ccès ?

Et puis il faut lire dans l'aide ce qui concerne le verrouillage des
enregistrements. Je te laisse découvrir la différence entre verrouill age
optimiste, pessimiste ... ça se passe dans les propriétés d'un jeu
d'enregistrements, qu'on précise au moment de l'ouvrir.

Il existe une notion de transaction qui doit aider la cohérence d'une
base, en empêchant qu'une table soit modifiée si une modification don née
n'a pas pu avoir lieu dans une autre table, mais hélas les essais que
j'ai eu l'occasion de faire de ça montraient que ça ne fonctionnait p as
dans Access. Cela étant, je les ai faits en version 97.
Donc il fallait monter une usine à gaz avec un champ auquel on commence
par donner une certaine valeur qui signifie pas touche, pareil dans
l'autre table, on fait les modifications des deux côtés, on enlève la
valeur pas touche, et puis voilà.

Ah oui tiens si tu as l'occasion d'essayer les transactions avec une
version plus récente ...

"Gloops" :

| John a écrit, le 12/09/2012 18:44 :
| quelles sont les méthodes à utiliser pour
| éviter deux (ou plus) accès simultanés à un recordset ?

Première chose, il va falloir regarder dans les options d'Access, parce
que par défaut, une fois qu'une base est ouverte sur une machine, aucune
autre ne peut y avoir accès

Désolé c'est ma faute : dans la table j'avais une clé primaire
qui n'était pas en AUTONUMBER, et c'est ca qui merdait :
deux accés *simultanés* en écriture tentaient d'inscrire le
*même* nombre en tant que clé primaire, donc conflit.

J'ai mis la base sur une 1e machine A ( en réseau )
Depuis une 2e machine B j'ouvre cette base, et en
même temps depuis une 3e machine C j'ouvre cette base,
depuis ces deux machines B & C je fais des saisies sur
les 2 formulaires puis je valide *en même temps* et
je n'ai plus de problème de conflit d'enregistrements.
.

Mais peut-être as-tu déjà vu cela si tu as pu essayer les accès ?

Il s'agit d'Access 2007 sous Win XP Pro sur un réseau local.
Le nombre d'utilisateurs simultanés pourra atteindre 20 personnes.
Note que l'extension du fichier Access est .ACCDB (et non pas .MDB)
mais je ne sais pas ce que cela implique ...
.

il faut regarder les propriétés concernées par le verrouillage.

Oui, c'est ce que je voulais éviter.

Maintenant le problème est que si deux utilisateurs
éditent et modifient un enregistrement *déja existant*,
et qu'ils valident tous les deux en même temps,
celui qui aura validé en dernier va écraser les
saisies de celui qui aura validé en premier ...

Je suppose que c'est un problème courant et connu,
et qu'il existe une technique simple pour l'éviter ?
( sans se taper 300 pages de documentation )

John a écrit, le 13/09/2012 18:36 :

"Gloops" :

| John a écrit, le 12/09/2012 18:44 :
| quelles sont les méthodes à utiliser pour
| éviter deux (ou plus) accès simultanés à un recordset ?

Première chose, il va falloir regarder dans les options d'Access,
parce que par défaut, une fois qu'une base est ouverte sur une
machine, aucune autre ne peut y avoir accès

Désolé c'est ma faute : dans la table j'avais une clé primaire
qui n'était pas en AUTONUMBER, et c'est ca qui merdait :
deux accés *simultanés* en écriture tentaient d'inscrire le
*même* nombre en tant que clé primaire, donc conflit.

J'ai mis la base sur une 1e machine A ( en réseau )
Depuis une 2e machine B j'ouvre cette base, et en
même temps depuis une 3e machine C j'ouvre cette base,
depuis ces deux machines B & C je fais des saisies sur
les 2 formulaires puis je valide *en même temps* et
je n'ai plus de problème de conflit d'enregistrements.
..

Ah oui pendant les formations on discute le bout de gras là-dessus
pendant une demi-heure une heure et on a l'impression d'échanger des
banalités, mais ... finalement, ce n'est pas inutile.

Donc alors on commence par verrouiller la table, puis on lit l'ancienne
clef sur le dernier enregistrement pour calculer la clef d'un nouvel
enregistrement, et ensuite on peut créer l'enregistrement, y écrire c e
qu'on a saisi avant, enregistrer et libérer le verrouillage.

Bien entendu, si quelqu'un a déjà accès à la table avant on ne pe ut pas
verrouiller, donc il faut attendre pour créer l'enregistrement. Sauf si
c'est juste un accès en lecture, auquel cas on a pris l'accès sans
verrouillage.

A priori, c'est une opération qui doit beaucoup se baser sur le bon sen s
pratique, lequel bien entendu doit pouvoir s'appuyer sur la connaissance
de ce qu'on a à disposition comme instructions d'accès et de verrouil lage.

C'est pour ça que je ne me rends pas bien compte si j'ai dit tout ce
qu'il y a à dire, ni si j'ai insisté un peu lourdement sur un point p ar
rapport à ce qui était nécessaire.

Autant sur les manipulations utilisateur je suis assez à l'aise pour
animer un cours, autant sur les verrouillages, j'imagine qu'il faut
mettre sur pied des exercices pour voir comment les gens s'en sortent et
évaluer si ils ont bien assimilé ce qu'il y a à assimiler. ça se peut
que j'aie ça à faire bientôt, d'ailleurs.

Donc, euh ... dis-moi à quel point c'est clair.

Mais peut-être as-tu déjà vu cela si tu as pu essayer les accè s ?

Il s'agit d'Access 2007 sous Win XP Pro sur un réseau local.
Le nombre d'utilisateurs simultanés pourra atteindre 20 personnes.
Note que l'extension du fichier Access est .ACCDB (et non pas .MDB)
mais je ne sais pas ce que cela implique ...
..

il faut regarder les propriétés concernées par le verrouillage.

Oui, c'est ce que je voulais éviter.

Ah ben oui mais ... c'est un point important. D'ailleurs je me rappelle,
quand on m'a demandé de migrer ma base arrière vers Oracle pour qu'on
puisse accéder à plusieurs en même temps, ça n'a marché qu'une fois que
j'ai trouvé cette option. Le principe est d'ailleurs le même si la ba se
arrière est sous Access, c'est juste que mon client n'a pas essayé le
multi-poste avec une base arrière en Access.

Maintenant le problème est que si deux utilisateurs
éditent et modifient un enregistrement *déja existant*,
et qu'ils valident tous les deux en même temps,
celui qui aura validé en dernier va écraser les
saisies de celui qui aura validé en premier ...

Je suppose que c'est un problème courant et connu,
et qu'il existe une technique simple pour l'éviter ?
( sans se taper 300 pages de documentation )

C'est-à-dire que si on commence par verrouiller le champ, avant
d'autoriser la saisie, l'autre utilisateur ne pourra de toute manière
pas saisir autre chose, puisque l'enregistrement est verrouillé. Donc,
comme ça, c'est simple.

Après, on peut se dire que si on verrouille pendant tout le temps qu'on
va saisir les modifications sur l'enregistrement, il va rester
verrouillé un bon bout de temps, et ça risque de paraître longuet p our
l'autre utilisateur. Donc, là, on peut cogiter, tiens si je crée une
table avec les verrous, que je dis que cet enregistrement-là est en
cours de saisie, je peux laisser mon utilisateur le modifier, mais en le
prévenant que quelqu'un d'autre est en train de modifier le même
enregistrement ailleurs, donc il est en train de vivre dangereusement
... Peut-être d'ailleurs qu'on fractionnera l'information entre
plusieurs tables, en fonction de qui va fournir les informations.

Tu vois, ce que je dis là est déjà beaucoup moins simple, et d'aill eurs
beaucoup moins orthodoxe, aussi. C'est une recherche d'un compromis dans
le but d'un peu de souplesse. Mais ... si tu es hésitant, je te suggè re
de peut-être te cantonner à l'approche orthodoxe, verrouiller plutô t
trop que pas assez, et puis ... eh bien l'utilisateur attendra un peu.
On ne te recrutera peut-être pas dans une agence de voyages sur cette
base-là, mais si on est vingt, j'imagine qu'on ne va pas souvent essaye r
de travailler à plusieurs sur le même enregistrement ? Sinon eh bien il
faudra être patients :)

"Gloops" :

Ah oui pendant les formations on discute le bout de gras là-dessus pendant
une demi-heure une heure et on a l'impression d'échanger des banalités,
mais ... finalement, ce n'est pas inutile.
Donc alors on commence par verrouiller la table, puis on lit l'ancienne
clef sur le dernier enregistrement pour calculer la clef d'un nouvel
enregistrement, et ensuite on peut créer l'enregistrement, y écrire ce
qu'on a saisi avant, enregistrer et libérer le verrouillage.
Bien entendu, si quelqu'un a déjà accès à la table avant on ne peut pas
verrouiller, donc il faut attendre pour créer l'enregistrement. Sauf si
c'est juste un accès en lecture, auquel cas on a pris l'accès sans
verrouillage.
A priori, c'est une opération qui doit beaucoup se baser sur le bon sens
pratique, lequel bien entendu doit pouvoir s'appuyer sur la connaissance
de ce qu'on a à disposition comme instructions d'accès et de verrouillage.
C'est pour ça que je ne me rends pas bien compte si j'ai dit tout ce qu'il
y a à dire, ni si j'ai insisté un peu lourdement sur un point par rapport
à ce qui était nécessaire.

Tout d'abord, je veux que tu saches que j'apprécie ton aide.

( j'ai l'impression que <microsoft.public.fr.access> est désert )

Pour commencer, je ne suis pas du tout 'database designer',
mais à mon job on a besoin d'une base pour certains trucs
( je ne peux pas entrer trop dans les détails )
et c'est à moi qu'a été confié l'étude et la réalisation.
Au début j'ai utilisé au maximum les fonctionnalités internes d'Access
( relations entre tables liées, clés primaires, automatismes, etc )
pour assurer la consistance, mais j'ai eu de mauvaises surprises.
( je ne prétends pas que le problème soit uniquement dû à Access,
c'est aussi bien dû à l'incomplètude de mes connaissances )

J'ai tout repris from crash, avec des formulaires dont les champs
ne sont pas liés à des tables : je me charge de lire les champs saisis
puis de les écrire dans les bons champs des bonnes tables.
( et de conserver l'intégrité des champs de tables contenant
des entiers servant d'index pour pointer vers d'autres tables )
Au final, pour te donner une idée de la facon dont c'est fait,
TOUT est géré par du code Visual Basic : c'est pour moi la
seule facon de maitriser tout ce qui se passe dans cette base.
( et quand quelque chose déconne je sais corriger le bug )

J'imagine que cette facon de procéder te semble hérétique ...
J'aurais largement préféré m'appuyer sur les fonctionnalités
d'Access car cela m'aurait évité de tout faire 'à la main'
et m'aurait fait gagner du temps, mais je bosse sur
d'autres projets ( qui eux, sont mon métier ) et je n'ai
pas le temps ( ni l'envie ) de devenir 'designer Access'.

Bref, j'ai quand même pu maintenant aboutir
à une base qui tient trés correctement la route,
même s'il me reste quelques trucs à optimiser.

Autant sur les manipulations utilisateur je suis assez à l'aise pour
animer un cours, autant sur les verrouillages, j'imagine qu'il faut mettre
sur pied des exercices pour voir comment les gens s'en sortent et évaluer
si ils ont bien assimilé ce qu'il y a à assimiler. ça se peut que j'aie ça
à faire bientôt, d'ailleurs.
Donc, euh ... dis-moi à quel point c'est clair.

C'est trés clair.
De mon côté, je ne tiens pas à tout apprendre de MS-Access
comme si je devais en faire mon métier ( j'ai déja un métier :o)
Heureusement cela fait 25 ans que je pratique la programmation
( microprocesseurs, microcontroleurs, PC, etc )
alors quand un système met à disposition un langage
( même un langage aussi merdique que Visual Basic ) au moins
j'ai des outils pour m'en sortir et aboutir à une base correcte.

Ah ben oui mais ... c'est un point important. D'ailleurs je me rappelle,
quand on m'a demandé de migrer ma base arrière vers Oracle

C'est marrant que tu parles d'Oracle, parce-que dans les années
1998/2002 j'ai bossé là-dessus pour une boite de bio-informatique,
j'ai fait des interfaces réseau sous forme de programmes Windows
qui s'interfacaient à Oracle en PL/SQL ... j'écrivais mes logiciels sous
MS-Visual C++ en langage C ( ca au moins c'est un VRAI langage )
Et tout cela marchait nickel. Faut dire qu'Oracle, c'est pas Access ...

pour qu'on puisse accéder à plusieurs en même temps, ça n'a marché qu'une
fois que j'ai trouvé cette option. Le principe est d'ailleurs le même si
la base arrière est sous Access, c'est juste que mon client n'a pas essayé
le multi-poste avec une base arrière en Access.
C'est-à-dire que si on commence par verrouiller le champ, avant
d'autoriser la saisie, l'autre utilisateur ne pourra de toute manière pas
saisir autre chose, puisque l'enregistrement est verrouillé. Donc, comme
ça, c'est simple.
Après, on peut se dire que si on verrouille pendant tout le temps qu'on va
saisir les modifications sur l'enregistrement, il va rester verrouillé un
bon bout de temps, et ça risque de paraître longuet pour l'autre
utilisateur.

Disons que, tant que l'utilisateur est prévenu, c'est déja ca.
On peut même lui dire QUI est en train de modifier l'enregistrement,
ensuite c'est à lui de voir s'il veut contacter l'autre utilisateur ou pas.

Mais je vois un problème potentiel dans les flags de blocage :
si un utilisateur accède à un enregistrement pour le modifier,
on positionne les flags ( indiquant 'pas touche, c'est verouillé' )
mais imagine que l'utilisateur quitte Access 'sauvagement',
ou qu'il y ait une rupture réseau, ou que son PC plante :
dans la base les flags de verrouillage vont rester positionnés
et plus personne ne pourra accèder à l'enregistrement, non ?
( et il faudra appeler l'admin (moi) pour débloquer la bête ... )

Donc, là, on peut cogiter, tiens si je crée une table avec les verrous,
que je dis que cet enregistrement-là est en cours de saisie, je peux
laisser mon utilisateur le modifier, mais en le prévenant que quelqu'un
d'autre est en train de modifier le même enregistrement ailleurs, donc il
est en train de vivre dangereusement ... Peut-être d'ailleurs qu'on
fractionnera l'information entre plusieurs tables, en fonction de qui va
fournir les informations.

Oui, un des problèmes potentiels qu'il me reste à résoudre est celui-ci :
Si deux utilisateurs accèdent au même enregistrement en même temps,
il faut que je mette en place un truc pour que seul celui qui accède
en premier puisse modifier les données, mais en plus que l'autre
utilisateur soit prévenu que l'enregistrement est en cours de modif
par un autre utilisateur, histoire de lui éviter de saisir des données
qui au final seront de toutes facons écrasées par les données de l'autre.

Tu vois, ce que je dis là est déjà beaucoup moins simple, et d'ailleurs
beaucoup moins orthodoxe, aussi. C'est une recherche d'un compromis dans
le but d'un peu de souplesse. Mais ... si tu es hésitant, je te suggère de
peut-être te cantonner à l'approche orthodoxe, verrouiller plutôt trop que
pas assez, et puis ... eh bien l'utilisateur attendra un peu. On ne te
recrutera peut-être pas dans une agence de voyages sur cette base-là, mais
si on est vingt, j'imagine qu'on ne va pas souvent essayer de travailler à
plusieurs sur le même enregistrement ? Sinon eh bien il faudra être
patients :)

Dans ma base j'ai créé une table avec les noms des utilisateurs
autorisés, les niveaux des droits utilisateurs, les adresses email, etc.
Quand un utilisateur ouvre l'interface ( formulaire ) Access,
je récupère le login Windows de l'utilisateur et le recherche
dans la table pour y lire les informations le concernant.
( si l'utilisateur n'est pas dans la table, j'affiche un message
genre ' Access denied ' puis je ferme la base et quitte Access )
Sinon j'autorise ou bloque des fonctionnalités suivant les droits attribués.
C'est déja une première barrière pour éviter les embrouilles.

J'ai aussi implémenté une table de log où j'enregistre les évènements
( login utilisateur, date/time, action réalisée, etc ) comme ca s'il y a
une couille je pense pouvoir remonter l'historique pour débugger.
J'ai aussi écrit une fonction VBA pour envoyer automatiquement des emails
aux utilisateurs en fonctions des actions impliquées par leur action sur la
base.
Aujourd'hui cette base se tient bien (je n'ai pas à en rougir) mais
comme je te l'ai dit, il y a encore des trucs que je voudrais fignoler.

Par exemple, je ne comprends pas trop ce qui se passe réélement
lorsqu'un utilisateur, depuis sa machine 'X' , ouvre la base ACCDB
qui est physiquement sur une autre machine 'Y' ( via le réseau )
Est-ce que Access ouvre sur la machine locale 'X' de l'utilisateur
une copie de la base, ou est-ce que Access se contente
d'établir une connection avec la base qui est sur la machine 'Y' ?
Une conséquence de cette question est que dans le code VBA,
1 - Soit toutes les variables ( integer, chaines, etc )
sont uniquement locales sur la machine 'X'
( donc propres à chaque utilisateur connecté )
2 - Soit elles sont les mêmes pour tous les utilisateurs.
Evidemment ca fait une sacrée différence.

Je ne sais pas si mes questions sont bien claires ?

John a écrit, le 15/09/2012 12:17 :

Tout d'abord, je veux que tu saches que j'apprécie ton aide.

Tant mieux :)

( j'ai l'impression que <microsoft.public.fr.access> est désert )

C'est vrai qu'il y a des gens qui sont partis ...

Pour commencer, je ne suis pas du tout 'database designer',
mais à mon job on a besoin d'une base pour certains trucs
( je ne peux pas entrer trop dans les détails )
et c'est à moi qu'a été confié l'étude et la réalisation.
Au début j'ai utilisé au maximum les fonctionnalités internes d'A ccess
( relations entre tables liées, clés primaires, automatismes, etc )
pour assurer la consistance, mais j'ai eu de mauvaises surprises.
( je ne prétends pas que le problème soit uniquement dû à Acces s,
c'est aussi bien dû à l'incomplètude de mes connaissances )

J'ai mis trois ans à maîtriser Access en m'accrochant, et j'avais dé jà
des notions au départ. Au bout de dix ans, je jette à peine un coup
d'oeil à l'aide de temps à autre.

Un point sur lequel on insiste trop rarement : c'est une grave erreur de
confier le développement d'une base Access à quelqu'un qui n'est pas
solide sur une méthode d'analyse, comme par exemple Merise. C'est comme
ça qu'on voit fleurir des bases avec un centre qui comporte dix
praticiens, et on crée un deuxième centre quand il y en a un onzièm e
praticien dans le même centre. C'est juste un exemple.

Sur Merise on trouve des docs pas trop mal fichues, il y a des gens qui
proposent des formations aussi. En deux semaines on peut avoir une
initiation valable.

J'ai tout repris from crash, avec des formulaires dont les champs
ne sont pas liés à des tables : je me charge de lire les champs sai sis
puis de les écrire dans les bons champs des bonnes tables.
( et de conserver l'intégrité des champs de tables contenant
des entiers servant d'index pour pointer vers d'autres tables )
Au final, pour te donner une idée de la facon dont c'est fait,
TOUT est géré par du code Visual Basic : c'est pour moi la
seule facon de maitriser tout ce qui se passe dans cette base.
( et quand quelque chose déconne je sais corriger le bug )

La création dynamique de champs est utile dans certaines situations.
Notamment, quand on a déployé une base de données, et que la base d e
traitement prend en compte un nouveau champ : la base de traitement doit
alors créer le nouveau champ par code, sinon on est tranquille qu'un
jour ou l'autre on va se tromper de base de données et se retrouver ave c
le message "champ inconnu".

En dehors de cela, l'interface utilisateur ne me paraît pas attirer de
reproche majeur, ça va quand même plus vite de créer un champ avec, que
d'écrire le code pour le faire, puis l'exécuter. Une réserve quand même,
c'est vrai que l'interface utilisateur évolue assez régulièrement, alors
que Dieu merci l'environnement de développement conserve plus de stabil ité.

J'imagine que cette facon de procéder te semble hérétique ...
J'aurais largement préféré m'appuyer sur les fonctionnalités
d'Access car cela m'aurait évité de tout faire 'à la main'
et m'aurait fait gagner du temps, mais je bosse sur
d'autres projets ( qui eux, sont mon métier ) et je n'ai
pas le temps ( ni l'envie ) de devenir 'designer Access'.

Depuis environ cinq ans, les entreprises hésitent bien plus à faire
appel aux compétences, du coup les utilisateurs doivent se débrouille r
par leurs propres moyens. Quand on sera sortis de ça, ça augure des
missions de maintenance hautement joyeuses.

Bref, j'ai quand même pu maintenant aboutir
à une base qui tient trés correctement la route,
même s'il me reste quelques trucs à optimiser.

C'est au moins une bonne chose :)

C'est trés clair.

Bonne nouvelle. C'est généralement ce qu'on me dit, mais il ne faut
jamais le considérer comme définitivement acquis.

De mon côté, je ne tiens pas à tout apprendre de MS-Access
comme si je devais en faire mon métier ( j'ai déja un métier :o)
Heureusement cela fait 25 ans que je pratique la programmation
( microprocesseurs, microcontroleurs, PC, etc )
alors quand un système met à disposition un langage
( même un langage aussi merdique que Visual Basic ) au moins
j'ai des outils pour m'en sortir et aboutir à une base correcte.

Il me semble que Visual Basic est conçu pour être lisible par des gen s
qui ne l'ont pas appris. ça fait que l'utilisateur peut avoir une idé e
de ce qu'il y a dedans. Si jamais on s'est mal compris, je ne dirais pas
que c'est le moyen de correction par excellence parce que ça prendrait
quand même pas mal de temps à l'utilisateur, mais au moins si il veut le
lire il peut.

Quand à dire que c'est un langage merdique ... moins compact que C,
c'est sûr. Probablement ne le choisit-on pas pour les mêmes raisons.

D'ailleurs à présent, Microsoft propose de faire de la programmation
pour le pack Office avec la plateforme .Net : C#, VB.Net, C++ ...
Je n'ai pas encore vu se dessiner une demande forte là-dessus, mais
c'est une piste à ne pas négliger. Cela étant, comme il faut quand même
plus de temps pour y entrer que pour ouvrir un module VBA, c'est
probablement davantage destiné à des gens dont c'est le métier de
programmer, et qui savent poser les bonnes question grâce à une mét hode
d'analyse éprouvée. On en attend un code plus cher à produire au dé part,
mais qui est supposé durer -tant que l'aspect fonctionnel n'évolue pa s,
ou encore le système d'exploitation.

Ah ben oui mais ... c'est un point important. D'ailleurs je me
rappelle, quand on m'a demandé de migrer ma base arrière vers Orac le

C'est marrant que tu parles d'Oracle, parce-que dans les années
1998/2002 j'ai bossé là-dessus pour une boite de bio-informatique,
j'ai fait des interfaces réseau sous forme de programmes Windows
qui s'interfacaient à Oracle en PL/SQL ... j'écrivais mes logiciels sous
MS-Visual C++ en langage C ( ca au moins c'est un VRAI langage )
Et tout cela marchait nickel. Faut dire qu'Oracle, c'est pas Access ...

Sinon, il n'y aurait pas de raison qu'il y ait deux noms :o)

Disons que, tant que l'utilisateur est prévenu, c'est déja ca.
On peut même lui dire QUI est en train de modifier l'enregistrement,
ensuite c'est à lui de voir s'il veut contacter l'autre utilisateur o u pas.

Mais je vois un problème potentiel dans les flags de blocage :
si un utilisateur accède à un enregistrement pour le modifier,
on positionne les flags ( indiquant 'pas touche, c'est verouillé' )
mais imagine que l'utilisateur quitte Access 'sauvagement',
ou qu'il y ait une rupture réseau, ou que son PC plante :
dans la base les flags de verrouillage vont rester positionnés
et plus personne ne pourra accèder à l'enregistrement, non ?
( et il faudra appeler l'admin (moi) pour débloquer la bête ... )

Exactement. C'est pour ça que c'est important de mettre à sa disposit ion
un champ qui lui dise qui a demandé le verrouillage et quand. Si ça
remonte à la veille, et que les utilisateurs sont bien "briefés" sur la
nécessité d'éteindre leur poste de travail le soir en partant, on s ait
que c'est un plantage et qu'on peut fermer. Si c'est récent on contacte
l'utilisateur pour savoir où il en est ...

Oui, un des problèmes potentiels qu'il me reste à résoudre est ce lui-ci :
Si deux utilisateurs accèdent au même enregistrement en même temp s,
il faut que je mette en place un truc pour que seul celui qui accède
en premier puisse modifier les données, mais en plus que l'autre
utilisateur soit prévenu que l'enregistrement est en cours de modif
par un autre utilisateur, histoire de lui éviter de saisir des donné es
qui au final seront de toutes facons écrasées par les données de l'autre.

Absolument. Vraisemblablement, pendant que quelqu'un d'autre modifie, on
peut lire, mais c'est une mauvaise idée d'autoriser la modification.

En fonction des détails fonctionnels de l'application, il peut
apparaître qu'un découpage des données soit judicieux, pour qu'une
personne modifie une partie, pendant qu'une autre modifie une autre.
Dans ce cas je verrais bien définir deux tables, bien que j'aie entendu
ériger le contraire en principe, mais si on veut que deux utilisateurs
puissent modifier deux parties d'un enregistrement en même temps, il
faut que le système d'exploitation, le système de gestion de base de
données et le langage le permettent. Je n'en connais pas d'exemple.

Dans ma base j'ai créé une table avec les noms des utilisateurs
autorisés, les niveaux des droits utilisateurs, les adresses email, e tc.
Quand un utilisateur ouvre l'interface ( formulaire ) Access,
je récupère le login Windows de l'utilisateur et le recherche
dans la table pour y lire les informations le concernant.
( si l'utilisateur n'est pas dans la table, j'affiche un message
genre ' Access denied ' puis je ferme la base et quitte Access )
Sinon j'autorise ou bloque des fonctionnalités suivant les droits
attribués.
C'est déja une première barrière pour éviter les embrouilles.

Oui, effectivement. D'ailleurs, selon le cas, il peut arriver qu'il soit
utile de se demander si l'utilisateur peut lire le code.

Il est à noter qu'Access propose un système de gestion de sécurité , avec
des groupes de connexion stockés dans un fichier d'extension mdw, et qu i
accorde des droits par objets (formulaires, tables ...). Ce n'est
peut-être pas une panacée, mais ça a au moins le mérite d'exister .

J'ai aussi implémenté une table de log où j'enregistre les évè nements
( login utilisateur, date/time, action réalisée, etc ) comme ca s'i l y a
une couille je pense pouvoir remonter l'historique pour débugger.

Effectivement. Bien réfléchir à ce qui se passe en cas de plantage, voir
si le système a le temps d'écrire dans la table de log. ça suppose un
gestionnaire d'erreur bien écrit.

J'ai aussi écrit une fonction VBA pour envoyer automatiquement des e mails
aux utilisateurs en fonctions des actions impliquées par leur action sur
la base.

Oui, c'est une idée, d'ailleurs SQL Server propose ça de façon
automatique en fonction de l'évolution d'un champ par exemple.

ça peut être une bonne idée d'en parler avec l'administrateur des m ails
de la boîte. C'est lui qui a connaissance des abus qui peuvent se
présenter, des blocages qu'il peut être amené à mettre en place,
éventuellement de finesses à apporter au protocole.

Aujourd'hui cette base se tient bien (je n'ai pas à en rougir) mais
comme je te l'ai dit, il y a encore des trucs que je voudrais fignoler.

Par exemple, je ne comprends pas trop ce qui se passe réélement
lorsqu'un utilisateur, depuis sa machine 'X' , ouvre la base ACCDB
qui est physiquement sur une autre machine 'Y' ( via le réseau )
Est-ce que Access ouvre sur la machine locale 'X' de l'utilisateur
une copie de la base, ou est-ce que Access se contente
d'établir une connection avec la base qui est sur la machine 'Y' ?
Une conséquence de cette question est que dans le code VBA,
1 - Soit toutes les variables ( integer, chaines, etc )
sont uniquement locales sur la machine 'X'
( donc propres à chaque utilisateur connecté )
2 - Soit elles sont les mêmes pour tous les utilisateurs.
Evidemment ca fait une sacrée différence.

Je ne sais pas si mes questions sont bien claires ?

Oui, très clair, mais là, plutôt que de dire des bêtises, au suje t
d'informations qui seraient enregistrées en cache sur le disque et qui
poseraient un problème de confidentialité, je vais te laisser cherche r
toi-même :)

Pour ce qui est de la portée des variables on doit pouvoir creuser.
Tu as une base de données, à l'arrière, qui contient les données, et une
base frontale sur la machine de chaque utilisateur. A priori, les
variables globales sont au niveau de la base, pour le frontal on a
chacun la sienne. C'est une bonne idée de faire quelques tests pour bie n
avoir le coeur net quant à éviter toute ambiguïté.

"Gloops" :

J'ai mis trois ans à maîtriser Access en m'accrochant, et j'avais déjà des
notions au départ. Au bout de dix ans, je jette à peine un coup d'oeil à
l'aide de temps à autre.

De mon côté c'est la même chose mais dans d'autre domaines.
Je trouve que les bases de données sont un truc vraiment intéréssant,
( surtout si on y ajoute les connectivités qu'apporte internet, etc ... )
mais j'ai un job pointu et passionnant qui me prend tout mon temps
alors je ne veux pas m'investir dans 'encore un autre nouveau domaine'.
Soit on s'investit à fond, soit on butine, mais quand ca m'intéresse
j'y vais à fond et ca prend pas mal de temps, qui n'est plus
consacré à mon métier 'de base'. ( enfin, voilà pour l'apparté )

Un point sur lequel on insiste trop rarement : c'est une grave erreur de
confier le développement d'une base Access à quelqu'un qui n'est pas
solide sur une méthode d'analyse, comme par exemple Merise.

Je suis tout à fait d'accord, mais il y a des situations professionnelles
ou l'on est embarqué et on ne peut pas vraiment refuser.
Si tu te ballades à la campagne au bord d'une rivière
et que tu vois quelqu'un qui se noie, tu le sauveras même
si tu n'es pas sauveteur professionnel ni maitre-nageur ;o)

C'est comme ça qu'on voit fleurir des bases avec un centre qui comporte
dix praticiens, et on crée un deuxième centre quand il y en a un onzième
praticien dans le même centre. C'est juste un exemple.
Sur Merise on trouve des docs pas trop mal fichues, il y a des gens qui
proposent des formations aussi. En deux semaines on peut avoir une
initiation valable.
La création dynamique de champs est utile dans certaines situations.
Notamment, quand on a déployé une base de données, et que la base de
traitement prend en compte un nouveau champ : la base de traitement doit
alors créer le nouveau champ par code, sinon on est tranquille qu'un jour
ou l'autre on va se tromper de base de données et se retrouver avec le
message "champ inconnu".
En dehors de cela, l'interface utilisateur ne me paraît pas attirer de
reproche majeur, ça va quand même plus vite de créer un champ avec, que
d'écrire le code pour le faire, puis l'exécuter. Une réserve quand même,
c'est vrai que l'interface utilisateur évolue assez régulièrement, alors
que Dieu merci l'environnement de développement conserve plus de
stabilité.

Y aurait-il eu confusion ? Je ne crée pas dynamiquement de champ, ni dans
les formulaires ni dans les tables. Tout cela est fixé au départ et ne bouge
plus.
( c'est déja ca )

Depuis environ cinq ans, les entreprises hésitent bien plus à faire appel
aux compétences, du coup les utilisateurs doivent se débrouiller par leurs
propres moyens. Quand on sera sortis de ça, ça augure des missions de
maintenance hautement joyeuses.

Tout à fait.
J'ai eu ce problème avec des clients qui s'amusaient à trafiquer
les fichiers de config ( genre .INI ) ou des entrées de la base
de registres de Windows, ou carrément éditer un exécutable
avec un éditeur hexadécimal pour trafiquer les chaines ASCII.
Et quand ca plante ils se plaignent au SAV ...
Quand je constatais de tels 'sabotages' je suggèrais à
mon boss de facturer au prix fort pour inciter LEUR boss
à faire un sérieux ménage ... en général, ca marche bien.

Il me semble que Visual Basic est conçu pour être lisible par des gens qui
ne l'ont pas appris. ça fait que l'utilisateur peut avoir une idée de ce
qu'il y a dedans. Si jamais on s'est mal compris, je ne dirais pas que
c'est le moyen de correction par excellence parce que ça prendrait quand
même pas mal de temps à l'utilisateur, mais au moins si il veut le lire il
peut.

De mon point de vue, l'utilisateur d'une base de données n'a rien à faire
dans le code VBA ni dans les créations de tables ou de formulaires.
S'il veut une fonctionnalité il la demande, et si c'est justifié, on
l'implémente.

Quand à dire que c'est un langage merdique ... moins compact que C, c'est
sûr. Probablement ne le choisit-on pas pour les mêmes raisons.

Je plaisantais ( à demi )

D'ailleurs à présent, Microsoft propose de faire de la programmation pour
le pack Office avec la plateforme .Net : C#, VB.Net, C++ ...
Je n'ai pas encore vu se dessiner une demande forte là-dessus, mais c'est
une piste à ne pas négliger. Cela étant, comme il faut quand même plus de
temps pour y entrer que pour ouvrir un module VBA, c'est probablement
davantage destiné à des gens dont c'est le métier de programmer, et qui
savent poser les bonnes question grâce à une méthode d'analyse éprouvée.
On en attend un code plus cher à produire au départ, mais qui est supposé
durer -tant que l'aspect fonctionnel n'évolue pas, ou encore le système
d'exploitation.

On ne va pas commencer une polémique sur les langages
de programmation, mais je ne vois pas l'intérêt de multiplier
les langages dans la mesure où il en existe déja qui sont majeurs,
bien éprouvés, lisibles, et pouvant évoluer pour des besoins nouveaux.
Certains même développent (sic) un 'snobisme' parfois agacant,
en défendant bec et ongles un langage plutôt qu'un autre.
Les critères sont la fiabilité, la facilité, la lisibilité, etc.
Sorti de là c'est la même polémique que les gens
qui ont une voiture de telle ou telle marque ...
( zut, j'avais pourtant dit que je ne me laisserais
pas entrainer mais je m'y suis laissé prendre ! )

C'est pour ça que c'est important de mettre à sa disposition un champ qui
lui dise qui a demandé le verrouillage et quand. Si ça remonte à la
veille, et que les utilisateurs sont bien "briefés" sur la nécessité
d'éteindre leur poste de travail le soir en partant, on sait que c'est un
plantage et qu'on peut fermer. Si c'est récent on contacte l'utilisateur
pour savoir où il en est ...

Oui.

En fonction des détails fonctionnels de l'application, il peut apparaître
qu'un découpage des données soit judicieux, pour qu'une personne modifie
une partie, pendant qu'une autre modifie une autre.

Certes mais là je n'ai pas ce genre de problème.
La structure des données dans la base est relativement simple
( pour par exemple quelqu'un comme toi qui est un professionnel
du domaine et qui - j'imagine - en a vu bien d'autres )
donc c'est assez blindé de ce côté-là.

Dans ce cas je verrais bien définir deux tables, bien que j'aie entendu
ériger le contraire en principe, mais si on veut que deux utilisateurs
puissent modifier deux parties d'un enregistrement en même temps, il faut
que le système d'exploitation, le système de gestion de base de données et
le langage le permettent. Je n'en connais pas d'exemple.

selon le cas, il peut arriver qu'il soit utile de se demander si
l'utilisateur peut lire le code.

Pour mon appli, c'est exclu. Non seulement la modif du code
est interdite, mais même la lecture seule n'est pas souhaitable.

Il est à noter qu'Access propose un système de gestion de sécurité, avec
des groupes de connexion stockés dans un fichier d'extension mdw, et qui
accorde des droits par objets (formulaires, tables ...). Ce n'est
peut-être pas une panacée, mais ça a au moins le mérite d'exister.

Là tu touches un point important. J'ai vu ca il y a quelques
années, mais je ne sais pas (encore) le mettre en place.

Effectivement. Bien réfléchir à ce qui se passe en cas de plantage, voir
si le système a le temps d'écrire dans la table de log. ça suppose un
gestionnaire d'erreur bien écrit.

Ca ne va pas aussi loin. Si des données erronnées sont
dans la base, je pense juste utiliser le log pour identifier
les utilisateurs qui étaient sur la base à l'instant du plantage,
et remonter à ce qu'ils ont fait qui aurait pu causer le problème.

Oui, très clair, mais là, plutôt que de dire des bêtises, au sujet
d'informations qui seraient enregistrées en cache sur le disque et qui
poseraient un problème de confidentialité, je vais te laisser chercher
toi-même :)

Là, je n'ai rien compris à ce que tu dis :o)

Pour ce qui est de la portée des variables on doit pouvoir creuser.
Tu as une base de données, à l'arrière, qui contient les données, et une
base frontale sur la machine de chaque utilisateur. A priori, les
variables globales sont au niveau de la base, pour le frontal on a chacun
la sienne. C'est une bonne idée de faire quelques tests pour bien avoir le
coeur net quant à éviter toute ambiguïté.

Oui, je vais faire ca.

C'est intéréssant d'avoir à la fois des variables propres à chaque
session ET des variables identiques pour toutes les sessions.

Par exemple :

Les droits utilisateurs sont propres à chacun
donc les variables qui y font référence doivent être
LOCALES à chaque PC qui ouvre la base via le réseau.
Si ce n'est pas le cas et que ces variables sont globales,
un utilisateur de bas niveau ayant des droits restreints
pourrait se retrouver avec des droits plus élevés
( et faire des modifs interdites )
Inversement, un utilisateur de haut niveau ayant des droits
étendus pourrait se retrouver avec des droits restreints
et ne pourrait plus utiliser la base à cause des restrictions.

D'un autre côté, une variable GLOBALE pourrait être mise à jour
à chaque fois qu'un utilisateur se connecte ou se déconnecte :
cela pemettrait de connaitre le nombre d'utilisateurs connectés
sur la base à un instant T ... (par exemple pour faire du 'ménage'
ou du back-up automatiquement quand personne n'est connecté)

Mais j'ai un sérieux doute quand à l'existence de variables
globales en VBA sur différentes sessions sur différents PC :
car cela implique que, lors de la modif de cette variable globale sur
n'importe lequel des postes utilisateurs, Access doit maintenir la valeur
de cette variable en la mettant à jour toutes les sessions en cours,
tout cela via le réseau, etc. Je ne sais pas pourquoi, mais j'ai un doute.

PS : Ce ne sont là que des exemples.

John a écrit, le 15/09/2012 15:15 :

"Gloops" :

J'ai mis trois ans à maîtriser Access en m'accrochant, et j'avais déjà
des notions au départ. Au bout de dix ans, je jette à peine un cou p
d'oeil à l'aide de temps à autre.

De mon côté c'est la même chose mais dans d'autre domaines.
Je trouve que les bases de données sont un truc vraiment intéréss ant,
( surtout si on y ajoute les connectivités qu'apporte internet, etc . .. )
mais j'ai un job pointu et passionnant qui me prend tout mon temps
alors je ne veux pas m'investir dans 'encore un autre nouveau domaine'.
Soit on s'investit à fond, soit on butine, mais quand ca m'intéress e
j'y vais à fond et ca prend pas mal de temps, qui n'est plus
consacré à mon métier 'de base'. ( enfin, voilà pour l'apparté )

Ah ben oui. Pour ma part j'ai laissé tomber ce que je faisais avant pou r
me consacrer à l'informatique, et je ne regrette pas. Alors il a dû y
avoir des gens qui ont été tentés par ce chemin pour la sécurité de
l'emploi, pour eux ça doit être dur, en ce moment. Pour les autres au ssi
d'ailleurs mais si au moins on fait quelque chose qu'on aime c'est déjà ça.

Je suis tout à fait d'accord, mais il y a des situations professionne lles
ou l'on est embarqué et on ne peut pas vraiment refuser.
Si tu te ballades à la campagne au bord d'une rivière
et que tu vois quelqu'un qui se noie, tu le sauveras même
si tu n'es pas sauveteur professionnel ni maitre-nageur ;o)

Là aussi il y a plusieurs niveaux. Si on arrive avec juste sa bonne
volonté on peut tendre la main avant que la personne se noie, si on
arrive juste un peu après c'est trop tard.

Après il y a le niveau premier secours, qui prend une semaine environ à
acquérir, plus un rafraichissement d'un week-end chaque année, ça p ermet
de parer au plus pressé en attendant que les vrais secours arrivent. On
met sur le côté pour que la victime ne s'étouffe pas en vomissant, si
elle ne respire plus on masse la respiration et le coeur, on fait
appeler les secours en leur fournissant les bons renseignements, en
précisant bien de ne pas raccrocher sans l'accord de la personne qui a
répondu. ça permet de tenir vingt minutes le temps que les pompiers
arrivent, un peu plus quelquefois (a priori on doit s'entraîner pour
être capable de pomper quarante minutes, là suffit pas de le dire -c' est
plus facile si on est plusieurs d'ailleurs).

Puis le niveau vrai secouriste, qui s'est formé en deux à trois
semaines, pour faire des permanences sur les grands rassemblements, une
fois équipé est capable de prendre en charge une palette plus vaste d e
problèmes, et de remettre les victimes d'aplomb sans qu'il soit besoin
d'autre intervention derrière.

Le niveau après, à ma connaissance, c'est professionnel de santé, d u
coup il y a un écart de niveau plus important (la standardiste je ne
sais pas, mais c'est clair que pour être médecin ...)

Y aurait-il eu confusion ? Je ne crée pas dynamiquement de champ, ni dans
les formulaires ni dans les tables. Tout cela est fixé au départ et ne
bouge plus.
( c'est déja ca )

Tu n'avais pas dit que tu le faisais par VBA ?

Tout à fait.
J'ai eu ce problème avec des clients qui s'amusaient à trafiquer
les fichiers de config ( genre .INI ) ou des entrées de la base
de registres de Windows, ou carrément éditer un exécutable
avec un éditeur hexadécimal pour trafiquer les chaines ASCII.

ça, me rappelle que j'y ai joué, une fois, avant d'être informatici en.
J'ai modifié un octet dans le pilote de clavier, pour que les majuscule s
restent verrouillées jusqu'à appuyer une deuxième fois sur verrouil lage
majuscules. Je n'étais pas mécontent de mon fait. Mais avec la versio n
suivante ce n'était plus possible.

Mais j'avais fait une copie, avant.

Et quand ca plante ils se plaignent au SAV ...
Quand je constatais de tels 'sabotages' je suggèrais à
mon boss de facturer au prix fort pour inciter LEUR boss
à faire un sérieux ménage ... en général, ca marche bien.

Ouaip

De mon point de vue, l'utilisateur d'une base de données n'a rien à faire
dans le code VBA ni dans les créations de tables ou de formulaires.
S'il veut une fonctionnalité il la demande, et si c'est justifié, o n
l'implémente.

C'est vrai que le langage fourni avec le produit encourage une confusion
des rôles. ça aide ceux qui ont la vocation à s'initier au départ , et
après ils se forment pour de bon pour franchir le pas, mais ceux qui ne
l'ont pas vraiment pataugent un peu dedans et laissent du bazar derrièr e
eux.

On ne devrait pas pousser vers là des gens qui n'en ont pas envie.

Quand à dire que c'est un langage merdique ... moins compact que C,
c'est sûr. Probablement ne le choisit-on pas pour les mêmes raison s.

Je plaisantais ( à demi )

un peu pour ce que je viens de dire ?

On ne va pas commencer une polémique sur les langages
de programmation, mais je ne vois pas l'intérêt de multiplier
les langages dans la mesure où il en existe déja qui sont majeurs,
bien éprouvés, lisibles, et pouvant évoluer pour des besoins nouv eaux.
Certains même développent (sic) un 'snobisme' parfois agacant,
en défendant bec et ongles un langage plutôt qu'un autre.
Les critères sont la fiabilité, la facilité, la lisibilité, etc .
Sorti de là c'est la même polémique que les gens
qui ont une voiture de telle ou telle marque ...
( zut, j'avais pourtant dit que je ne me laisserais
pas entrainer mais je m'y suis laissé prendre ! )

C'est vrai, la co-existence de C# et VB.Net relève plus du marketing qu e
d'autre chose. Enfin si ça aide Microsoft à gagner sa croûte ...

Il est à noter qu'Access propose un système de gestion de sécuri té,
avec des groupes de connexion stockés dans un fichier d'extension md w,
et qui accorde des droits par objets (formulaires, tables ...). Ce
n'est peut-être pas une panacée, mais ça a au moins le mérite d'exister.

Là tu touches un point important. J'ai vu ca il y a quelques
années, mais je ne sais pas (encore) le mettre en place.

Ah c'est vrai qu'il faut prendre le temps de lire la doc et
d'expérimenter. En fait je l'ai fait une fois, pour le refaire il
faudrait que je me replonge dedans. Et c'est peu probable, vu que à que l
point j'ai déjà un pied sur .Net ...

Ca ne va pas aussi loin. Si des données erronnées sont
dans la base, je pense juste utiliser le log pour identifier
les utilisateurs qui étaient sur la base à l'instant du plantage,
et remonter à ce qu'ils ont fait qui aurait pu causer le problème.

Ah, oui, on a écrit ça avant le plantage ?
Mais ça n'empêche pas d'avoir des procédures d'erreur propres, ça ne
prend pas des mois à apprendre à faire ...
Et d'ailleurs, ça permet de fermer la table, ça évite de perdre les
écritures en cours (ah oui attention, si tu ne fermes pas ta table, tu
risques de ne pas savoir qui était là).

Oui, très clair, mais là, plutôt que de dire des bêtises, au s ujet
d'informations qui seraient enregistrées en cache sur le disque et q ui
poseraient un problème de confidentialité, je vais te laisser cher cher
toi-même :)

Là, je n'ai rien compris à ce que tu dis :o)

Si tu manipules des données hautement confidentielles, ça serait bien de
faire venir quelqu'un dont c'est le métier de veiller au grain. Je ne
suis même pas sûr que je m'y frotterais.

Je me rappelle avec une des premières versions de Word, on pouvait
mettre un mot de passe sur chaque document. Sauf qu'on pouvait afficher
le document avec la commande TYPE du DOS, ça n'affichait pas le contenu ,
mais ça affichait le mot de passe en clair.

Plus tard, j'ai jeté un coup d'oeil dans un document d'une autre
version, j'ai lu dans le premier secteur des informations qui n'avaient
absolument rien à voir. Des adresses client, par exemple, qui n'avaient
rien à voir avec le destinataire du document. Tout ça dans un courrie r,
selon à qui tu l'envoies ça peut faire mal.

Quand on consulte un fichier présent sur un CD, le système en fait un e
copie en local sur le disque dur, pour pouvoir y avoir accès en
écriture, ça lui permet de gérer les verrouillages par exemple. Je
n'affirmerais pas qu'il n'en aille pas de même d'un fichier lu depuis u n
réseau. Avec des nuances puisque le réseau permet de le modifier.

Donc, en admettant que le fichier sur le réseau soit sécurisé avec un
mot de passe, il faut quand même avoir conscience que sa copie dans le
tampon ne l'est pas. En règle générale on ne s'en préoccupe pas, mais il
faut avoir conscience que l'espionnage industriel existe. Le plus
souvent un programmeur n'a pas toutes les compétences pour l'éviter,
mais réfléchir à des questions pratiques comme celle-là permet de
limiter les dégâts.

C'est intéréssant d'avoir à la fois des variables propres à cha que
session ET des variables identiques pour toutes les sessions.

Par exemple :

Les droits utilisateurs sont propres à chacun
donc les variables qui y font référence doivent être
LOCALES à chaque PC qui ouvre la base via le réseau.
Si ce n'est pas le cas et que ces variables sont globales,
un utilisateur de bas niveau ayant des droits restreints
pourrait se retrouver avec des droits plus élevés
( et faire des modifs interdites )
Inversement, un utilisateur de haut niveau ayant des droits
étendus pourrait se retrouver avec des droits restreints
et ne pourrait plus utiliser la base à cause des restrictions.

Oui et non. Les règles de sécurité sont communes à toute l'applic ation.
Il est vrai qu'il faut prendre des précautions pour que n'importe qui n e
puisse pas modifier la table qui définit les droits.

Il est vrai qu'on peut utiliser plusieurs approches.

L'autre jour quelqu'un a proposé une méthode du trousseau de clefs,
basée sur un octet dont chaque bit définit un droit, et chaque
utilisateur se voit confier un trousseau qui prend la forme d'un octet.
Il n'empêche que l'octet en question, il faut être sûr de l'attribu er de
manière fiable à l'utilisateur.

D'un autre côté, une variable GLOBALE pourrait être mise à jour
à chaque fois qu'un utilisateur se connecte ou se déconnecte :
cela pemettrait de connaitre le nombre d'utilisateurs connectés
sur la base à un instant T ... (par exemple pour faire du 'ménage'
ou du back-up automatiquement quand personne n'est connecté)

Oui à ce moment tu ne mets pas ça dans la base frontale, mais dans la
base de données derrière (a priori dans une table), puisque c'est à elle
que tu veux savoir combien il y a de personnes connectées. Attention à
ce qui se passe si deux personnes se connectent en même temps.

ça n'empêche pas d'y accéder par une table liée, d'ailleurs.

Et bien entendu il faut gérer le problème du plantage, au cours du qu el
quelqu'un se déconnecte sans décrémenter le compteur.

D'ailleurs, dans une table je stockerais bien le nom de l'utilisateur
qui se connecte, celui de sa machine, son adresse IP, et la date et
l'heure. ça permet de savoir qui est connecté et où, et depuis comb ien
de temps. Pour ce qui est de savoir depuis combien de temps, ça permet
de gérer les plantages, on en a déjà parlé.

Mais j'ai un sérieux doute quand à l'existence de variables
globales en VBA sur différentes sessions sur différents PC :
car cela implique que, lors de la modif de cette variable globale sur
n'importe lequel des postes utilisateurs, Access doit maintenir la vale ur
de cette variable en la mettant à jour toutes les sessions en cours,
tout cela via le réseau, etc. Je ne sais pas pourquoi, mais j'ai un d oute.

PS : Ce ne sont là que des exemples.

Là je croirais assez à la table de paramètres, ou d'options qui
généralement n'a qu'un seul enregistrement.

C'est vrai que les variables globales sous Access, ça me laisse un peu sec.

Le 15/09/2012 17:23, Gloops a écrit :

L'autre jour quelqu'un a proposé une méthode du trousseau de clefs,
basée sur un octet dont chaque bit définit un droit, et chaque
utilisateur se voit confier un trousseau qui prend la forme d'un octet.
Il n'empêche que l'octet en question, il faut être sûr de l'attribuer de
manière fiable à l'utilisateur.

Avant de remettre un trousseau de clefs à quelqu'un, je m'assure de son
identité à l'aide d'un login et d'un mot de passe. C'est élémentaire me
semble-t-il ? Cela permet aussi de suivre cette personne en établissant
un mouchard des actions importantes.

"Gloops" :

Je ne crée pas dynamiquement de champ, ni dans les formulaires ni dans
les tables. Tout cela est fixé au départ et ne bouge plus.

Tu n'avais pas dit que tu le faisais par VBA ?

Les formulaires et tables sont créés 'à la main' via l'interface Access,
et après ils ne bougent plus ; ils sont définis une fois pour toutes.
Ce que je fais en VBA c'est gérer tous les évènements liés aux
lectures/écritures des éléments des formulaires et des données
dans les tables, assurer la cohérence, gérer les droits d'accès, etc ...

ça, me rappelle que j'y ai joué, une fois, avant d'être informaticien.
J'ai modifié un octet dans le pilote de clavier, pour que les majuscules
restent verrouillées jusqu'à appuyer une deuxième fois sur verrouillage
majuscules. Je n'étais pas mécontent de mon fait. Mais avec la version
suivante ce n'était plus possible. Mais j'avais fait une copie, avant.

Ok, mais ca, ce n'est pas du 'sabotage' ...

Je plaisantais ( à demi )

un peu pour ce que je viens de dire ?

Ce que je reproche au Visual Basic est d'être assez opaque et
même parfois subtilement incompatible entre certaines versions.
Mais tout ca c'est la logique commerciale de MS.

Ca ne va pas aussi loin. Si des données erronnées sont
dans la base, je pense juste utiliser le log pour identifier
les utilisateurs qui étaient sur la base à l'instant du plantage,
et remonter à ce qu'ils ont fait qui aurait pu causer le problème.

Ah, oui, on a écrit ça avant le plantage ?

Il n'est pas question de gérer les plantages mais de
remonter à la cause d'éventuelles données erronnées.

Mais ça n'empêche pas d'avoir des procédures d'erreur propres, ça ne prend
pas des mois à apprendre à faire ...
Et d'ailleurs, ça permet de fermer la table, ça évite de perdre les
écritures en cours (ah oui attention, si tu ne fermes pas ta table, tu
risques de ne pas savoir qui était là).

Je ne comprends pas trés bien ta remarque. La table de log n'est
pas ouverte en début de session puis fermée en fin de session,
sinon en cas de crash je perdrais les écritures encore dans le cache.
Pour être plus précis, j'ai écrit une fonction qui prend en paramètre
une chaine ( décrivant l'évènement à mémoriser ) cette fonction ouvre
la table de log et y inscrit { user login , date/time , l'évènement }
puis ferme la table avant de rendre la main. La table n'est accédée en
écriture que pendant le court temps d'y inscrire un seul enregistrement.
On peut toujours imaginer qu'il y ait un crash justement à l'instant
où l'on exécute le code de cette fonction, mais cette probabilité
est plus faible que si la table était tout le temps ouverte.

Si tu manipules des données hautement confidentielles, ça serait bien de
faire venir quelqu'un dont c'est le métier de veiller au grain. Je ne suis
même pas sûr que je m'y frotterais.

Les données sont bien confidentielles et le niveau de
protection dont tu parles est assuré par l'admin IT de la boite.
Je lui ai demandé de bétonner l'accès de la base au niveau
réseau et serveur, avec la liste des seuls utilisateurs autorisés.
( qui sont eux-même les sources de ces données confidentielles,
ils sont donc 'trusted' puisqu'ils connaissent déja ces données )
Même par 'accident' personne d'autre ne peut y accéder, même pas
en lecture seule, et ceci n'est pas à ma charge mais à celle de l'admin IT.

Je me rappelle avec une des premières versions de Word, on pouvait mettre
un mot de passe sur chaque document. Sauf qu'on pouvait afficher le
document avec la commande TYPE du DOS, ça n'affichait pas le contenu, mais
ça affichait le mot de passe en clair.
Plus tard, j'ai jeté un coup d'oeil dans un document d'une autre version,
j'ai lu dans le premier secteur des informations qui n'avaient absolument
rien à voir. Des adresses client, par exemple, qui n'avaient rien à voir
avec le destinataire du document. Tout ça dans un courrier, selon à qui tu
l'envoies ça peut faire mal.
Quand on consulte un fichier présent sur un CD, le système en fait une
copie en local sur le disque dur, pour pouvoir y avoir accès en écriture,
ça lui permet de gérer les verrouillages par exemple. Je n'affirmerais pas
qu'il n'en aille pas de même d'un fichier lu depuis un réseau. Avec des
nuances puisque le réseau permet de le modifier.
Donc, en admettant que le fichier sur le réseau soit sécurisé avec un mot
de passe, il faut quand même avoir conscience que sa copie dans le tampon
ne l'est pas. En règle générale on ne s'en préoccupe pas, mais il faut
avoir conscience que l'espionnage industriel existe. Le plus souvent un
programmeur n'a pas toutes les compétences pour l'éviter, mais réfléchir à
des questions pratiques comme celle-là permet de limiter les dégâts.

Oui je suis bien conscient des problèmes que tu soulèves,
mais cette partie du travail est à la charge de l'admin IT.

Les droits utilisateurs sont propres à chacun
donc les variables qui y font référence doivent être
LOCALES à chaque PC qui ouvre la base via le réseau.
Si ce n'est pas le cas et que ces variables sont globales,
un utilisateur de bas niveau ayant des droits restreints
pourrait se retrouver avec des droits plus élevés
( et faire des modifs interdites )
Inversement, un utilisateur de haut niveau ayant des droits
étendus pourrait se retrouver avec des droits restreints
et ne pourrait plus utiliser la base à cause des restrictions.

Oui et non. Les règles de sécurité sont communes à toute l'application. Il
est vrai qu'il faut prendre des précautions pour que n'importe qui ne
puisse pas modifier la table qui définit les droits.
Il est vrai qu'on peut utiliser plusieurs approches.
L'autre jour quelqu'un a proposé une méthode du trousseau de clefs, basée
sur un octet dont chaque bit définit un droit, et chaque utilisateur se
voit confier un trousseau qui prend la forme d'un octet.
Il n'empêche que l'octet en question, il faut être sûr de l'attribuer de
manière fiable à l'utilisateur.

Oui, c'est bien ce dont je parlais.

D'un autre côté, une variable GLOBALE pourrait être mise à jour
à chaque fois qu'un utilisateur se connecte ou se déconnecte :
cela pemettrait de connaitre le nombre d'utilisateurs connectés
sur la base à un instant T ... (par exemple pour faire du 'ménage'
ou du back-up automatiquement quand personne n'est connecté)

Oui à ce moment tu ne mets pas ça dans la base frontale, mais dans la base
de données derrière

Là je suis à nouveau largué :
Il n'y a qu'un seul fichier ACCDB, il n'y a qu'une seule base.
Pourquoi parles-tu de deux bases ( frontale & derrière ) ?

(a priori dans une table), puisque c'est à elle que tu veux savoir
combien il y a de personnes connectées. Attention à ce qui se passe si
deux personnes se connectent en même temps.
ça n'empêche pas d'y accéder par une table liée, d'ailleurs.
Et bien entendu il faut gérer le problème du plantage, au cours du quel
quelqu'un se déconnecte sans décrémenter le compteur.

Tout çà fait.

D'ailleurs, dans une table je stockerais bien le nom de l'utilisateur qui
se connecte, celui de sa machine, son adresse IP, et la date et l'heure.

C'est ce que je fais avec ma fonction log.

ça permet de savoir qui est connecté et où, et depuis combien de temps.
Pour ce qui est de savoir depuis combien de temps, ça permet de gérer les
plantages, on en a déjà parlé.

Là je croirais assez à la table de paramètres, ou d'options qui
généralement n'a qu'un seul enregistrement.
C'est vrai que les variables globales sous Access, ça me laisse un peu
sec.

Mmmmh ...

John a écrit, le 15/09/2012 18:58 :

"Gloops" :

Je ne crée pas dynamiquement de champ, ni dans les formulaires ni
dans les tables. Tout cela est fixé au départ et ne bouge plus.

Tu n'avais pas dit que tu le faisais par VBA ?

Les formulaires et tables sont créés 'à la main' via l'interface Access,
et après ils ne bougent plus ; ils sont définis une fois pour toute s.
Ce que je fais en VBA c'est gérer tous les évènements liés aux
lectures/écritures des éléments des formulaires et des données
dans les tables, assurer la cohérence, gérer les droits d'accès, etc ...

Ah, d'acc ...

ça, me rappelle que j'y ai joué, une fois, avant d'être informat icien.
J'ai modifié un octet dans le pilote de clavier, pour que les
majuscules restent verrouillées jusqu'à appuyer une deuxième foi s sur
verrouillage majuscules. Je n'étais pas mécontent de mon fait. Mai s
avec la version suivante ce n'était plus possible. Mais j'avais fait
une copie, avant.

Ok, mais ca, ce n'est pas du 'sabotage' ...

:)

Ah oui le coup de l'apprenti sorcier ...

Je plaisantais ( à demi )

un peu pour ce que je viens de dire ?

Ce que je reproche au Visual Basic est d'être assez opaque et
même parfois subtilement incompatible entre certaines versions.
Mais tout ca c'est la logique commerciale de MS.

Ah, c'est marrant que tu trouves le VB opaque par rapport à C ...

Je ne comprends pas trés bien ta remarque. La table de log n'est
pas ouverte en début de session puis fermée en fin de session,
sinon en cas de crash je perdrais les écritures encore dans le cache.
Pour être plus précis, j'ai écrit une fonction qui prend en param ètre
une chaine ( décrivant l'évènement à mémoriser ) cette foncti on ouvre
la table de log et y inscrit { user login , date/time , l'évènement }
puis ferme la table avant de rendre la main. La table n'est accédée en
écriture que pendant le court temps d'y inscrire un seul enregistreme nt.
On peut toujours imaginer qu'il y ait un crash justement à l'instant
où l'on exécute le code de cette fonction, mais cette probabilité
est plus faible que si la table était tout le temps ouverte.

Ah, oui, c'est une solution.

Remarque bien que l'un n'empêche pas l'autre ...

Les données sont bien confidentielles et le niveau de
protection dont tu parles est assuré par l'admin IT de la boite.
Je lui ai demandé de bétonner l'accès de la base au niveau
réseau et serveur, avec la liste des seuls utilisateurs autorisés.
( qui sont eux-même les sources de ces données confidentielles,
ils sont donc 'trusted' puisqu'ils connaissent déja ces données )
Même par 'accident' personne d'autre ne peut y accéder, même pas
en lecture seule, et ceci n'est pas à ma charge mais à celle de l'a dmin IT.

Effectivement, j'imagine que c'est au-dessus de la moyenne ...

Oui à ce moment tu ne mets pas ça dans la base frontale, mais dans la
base de données derrière

Là je suis à nouveau largué :
Il n'y a qu'un seul fichier ACCDB, il n'y a qu'une seule base.
Pourquoi parles-tu de deux bases ( frontale & derrière ) ?

Tu n'as pas dit que plusieurs utilisateurs accédaient à l'application ?
Tu ne leur fais quand même pas ouvrir via le réseau une base qui
contient à la fois les données et le traitement ?

D'ailleurs, dans une table je stockerais bien le nom de l'utilisateur
qui se connecte, celui de sa machine, son adresse IP, et la date et
l'heure.

C'est ce que je fais avec ma fonction log.

Bien. Ah oui alors pour la lecture tu parcours le log, tu dis celui-là,
qui est entré là, est reparti à cette ligne-là ...
C'est ça ?