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 ?
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 ?
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 ?
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
Mais peut-être as-tu déjà vu cela si tu as pu essayer les accès ?
il faut regarder les propriétés concernées par le verrouillage.
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
Mais peut-être as-tu déjà vu cela si tu as pu essayer les accès ?
il faut regarder les propriétés concernées par le verrouillage.
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
Mais peut-être as-tu déjà vu cela si tu as pu essayer les accès ?
il faut regarder les propriétés concernées par le verrouillage.
"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 )
"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 )
"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 )
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.
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.
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 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.
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'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 :)
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.
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.
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 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.
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'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 :)
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.
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.
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 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.
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'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 :)
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'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 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 )
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.
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 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 ...
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 ... )
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.
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.
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.
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.
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 ?
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'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 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 )
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.
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 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 ...
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 ... )
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.
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.
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.
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.
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 ?
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'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 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 )
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.
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 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 ...
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 ... )
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.
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.
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.
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.
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 ?
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è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é.
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.
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.
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é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.
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 ...
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.
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 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.
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.
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 :)
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é.
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è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é.
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.
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.
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é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.
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 ...
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.
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 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.
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.
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 :)
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é.
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è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é.
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.
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.
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é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.
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 ...
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.
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 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.
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.
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 :)
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é.
"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é )
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)
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 )
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.
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.
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 )
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 ! )
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.
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 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)
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.
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 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.
"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é )
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)
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 )
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.
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.
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 )
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 ! )
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.
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 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)
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.
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 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.
"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é )
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)
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 )
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.
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.
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 )
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 ! )
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.
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 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)
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.
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 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'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.
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.
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.
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 ?
ç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.
Je plaisantais ( à demi )
un peu pour ce que je viens de dire ?
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à).
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 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.
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.
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 quel
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 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.
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 ?
ç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.
Je plaisantais ( à demi )
un peu pour ce que je viens de dire ?
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à).
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 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.
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.
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 quel
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 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.
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 ?
ç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.
Je plaisantais ( à demi )
un peu pour ce que je viens de dire ?
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à).
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 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.
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.
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 quel
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 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.
"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 ...
ç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' ...
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.
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.
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.
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 ) ?
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.
"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 ...
ç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' ...
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.
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.
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.
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 ) ?
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.
"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 ...
ç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' ...
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.
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.
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.
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 ) ?
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.