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

[John]

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 ?

[Gloops]

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, aucune
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ête,
désolé, mais une option permet l'accès concurrentiel depuis plusieurs
postes. Mais peut-être as-tu déjà vu cela si tu as pu essayer les accè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 verrouillage
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 donné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 pas
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 ...

[John]

"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 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 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.

>
>> 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 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.



>
> 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 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 :)

[John]

"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 ?

[Gloops]

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'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 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.

>
> 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 )


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é.



>
> 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ébrouiller
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 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.

>
>
>> 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 ...

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 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 ... )


Exactement. 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, 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.

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, 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.

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 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.

>
> 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.

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 emails
> 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 mails
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 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é.

[John]

"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.

[Gloops]

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 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é )


Ah ben oui. Pour ma part j'ai laissé tomber ce que je faisais avant pour
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 aussi
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 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)

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 permet
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 de
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é, du
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 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.

> 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é, on
> 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ère
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 raisons.
>
> 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 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 vrai, la co-existence de C# et VB.Net relève plus du marketing que
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é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.

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 à quel
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 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)


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.


> 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.

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é.

>
> 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.

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.

[Blaise]

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.

[John]

"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 ...

[Gloops]

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 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 ...


Ah, d'acc ...

>
>
>> ç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' ...

:)

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 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.


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'admin 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 ?

[Gloops]

Blaise a écrit, le 15/09/2012 18:47 :
> 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.
>

Ah ben oui.
Sauf qu'une base de données fonctionne un peu sur le principe d'un hôtel
: en sortant on met sa clef sur le tableau pour que le ménage puisse
être fait (enfin à quelques nuances près, l'allégorie vaut ce qu'elle
vaut ...)

Il faut faire bien attention, dans les options, de mettre le tableau de
clefs derrière l'accueil, plutôt que dans la rue comme c'est le cas par
défaut :)

[John]

"Gloops" .

>>> tu ne mets pas �a dans la base frontale, mais dans la base de donn�es
>>> derri�re

| 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 ?

Oui.

> 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 ?

Si. Je te vois presque sursauter ...
mais c'est pourqoi je te re-pose ma question pr�c�dente :
pourquoi plusieurs bases ?

[Gloops]

John a écrit, le 17/09/2012 18:09 :
>> 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 ?

>
> Si. Je te vois presque sursauter ...

> mais c'est pourqoi je te re-pose ma question précédente :
> pourquoi plusieurs bases ?
>
>

C'est la façon habituelle de travailler :
- ça facilite les mises à jour, car on peut modifier le code sans
toucher aux données
- ça allège le trafic sur le réseau, car il n'y a que les données qui
passent -à condition de mettre un exemplaire de la base frontale sur le
poste de chaque utilisateur.

Entre les deux, le lien se fait en général par les tables liées, qui au
demeurant servent à ça.

D'ailleurs, je me demande bien comment on peut travailler à plusieurs
sur la même base, si l'interface est dans le même fichier, donc par voie
de conséquence sur la même machine.

C'est à telle enseigne qu'Access propose un assistant pour effectuer le
fractionnement.

[John]

"Gloops" :

>> pourquoi plusieurs bases ?

> C'est la fa�on habituelle de travailler :
> - �a facilite les mises � jour, car on peut modifier le code sans toucher
> aux donn�es

Oui, ca c'est une (tr�s bonne) bonne raison.


> - �a all�ge le trafic sur le r�seau, car il n'y a que les donn�es qui
> passent -� condition de mettre un exemplaire de la base frontale sur le
> poste de chaque utilisateur.

Voil� peut-�tre un drawback : lors d'une mise � jour de
la base frontale il faut veiller � ce que tout le monde soit ok,
( mais ce n'est pas r�dhibitoire )
alors qu'avec un seul fichier, tout est forc�ment � jour.


> Entre les deux, le lien se fait en g�n�ral par les tables li�es, qui au
> demeurant servent � �a.

> D'ailleurs, je me demande bien comment on peut travailler � plusieurs sur
> la m�me base, si l'interface est dans le m�me fichier, donc par voie de
> cons�quence sur la m�me machine.

D'o� une de mes questions d'un post pr�c�dent :
si deux utilisateurs, depuis leurs machines A et B en r�seau,
ouvrent une base ACCDB situ�e sur une 3e machine C en r�seau,
quels sont les �l�ments de la base C (donn�es des tables, etc)
qui sont transf�r�s et/ou synchronis�s vers A et B
et quels sont ceux qui restent sur C ?

[Gloops]

John a écrit, le 18/09/2012 19:01 :
> "Gloops" :
>
>>> pourquoi plusieurs bases ?
>

>> C'est la façon habituelle de travailler :

>> - ça facilite les mises à jour, car on peut modifier le code sans
>> toucher aux données
>
> Oui, ca c'est une (trés bonne) bonne raison.

N'est-ce pas ?

Dans l'interface utilisateur il existe un gestionnaire de tables liées,
pour changer la base source pour toutes les tables à la fois. Cela étant
dit, concrètement, on ne va pas aller tous les mois derrière l'épaule de
chaque utilisateur, pour lui dire il faut cliquer là, non non là, oui,
puis là, et ensuite là ...

Donc, dans la procédure de mise à jour du code, on va introduire une
fonction de mise à jour des liens, table liée par table liée. On trouve
ça tout prêt sur Internet, au besoin.




>> - ça allège le trafic sur le réseau, car il n'y a que les données qui
>> passent -à condition de mettre un exemplaire de la base frontale sur

>> le poste de chaque utilisateur.
>

> Voilà peut-être un drawback : lors d'une mise à jour de
> la base frontale il faut veiller à ce que tout le monde soit ok,
> ( mais ce n'est pas rédhibitoire )
> alors qu'avec un seul fichier, tout est forcément à jour.

Pas dur, ça. Dans la table de paramètres on peut très bien mettre un
champ avec date et heure de mise à jour du code. A chaque chargement, la
base frontale lit ça, et comme elle sait quand elle a été créée, si la
date de mise à jour est plus récente :
- je dis à l'utilisateur que je ne suis pas à jour
- je déclenche le téléchargement
- j'indique à l'utilisateur où il faut cliquer
- je vais me coucher parce que tout ça m'a bien fatigué :)

C'est le principe, on peut affiner plus la procédure de mise à jour.

>> Entre les deux, le lien se fait en général par les tables liées, qui
>> au demeurant servent à ça.
>
>> D'ailleurs, je me demande bien comment on peut travailler à plusieurs
>> sur la même base, si l'interface est dans le même fichier, donc par
>> voie de conséquence sur la même machine.
>

> D'où une de mes questions d'un post précédent :
> si deux utilisateurs, depuis leurs machines A et B en réseau,
> ouvrent une base ACCDB située sur une 3e machine C en réseau,
> quels sont les éléments de la base C (données des tables, etc)
> qui sont transférés et/ou synchronisés vers A et B

> et quels sont ceux qui restent sur C ?

Pas dur, on crée des tables liées vers toutes les tables de la base C,
comme ça on dispose de toutes les données. Si une table n'a pas à être
mise à jour, on ne crée pas d'interface utilisateur qui la modifie.

La table des paramètres (ou des options) est un cas particulier : on met
à jour champ par champ, sur demande, et toujours sur le même
enregistrement. On peut préciser une clef quand même, des fois qu'un
jour on veuille conserver un jeu de paramètres en historique, et en
utiliser un autre. ça peut arriver, que les paramètres s'ajustent en
fonction de quelque chose à quoi on n'avait pas pensé.

[Gloops]

Gloops a écrit, le 19/09/2012 19:00 :
> La table des paramètres (ou des options) est un cas particulier : on met
> à jour champ par champ, sur demande, et toujours sur le même
> enregistrement. On peut préciser une clef quand même, des fois qu'un
> jour on veuille conserver un jeu de paramètres en historique, et en
> utiliser un autre. ça peut arriver, que les paramètres s'ajustent en
> fonction de quelque chose à quoi on n'avait pas pensé.

D'ailleurs, on peut avoir une table d'options sur la base source, qui
est commune à tout le monde, et une table de paramètres (non liée) sur
la base frontale, qui va être propre à l'utilisateur, où il pourra
adapter les éditions à son imprimante par exemple.

La date d'arrêté comptable est clairement commune à tout le monde,
d'autres champs peuvent mériter plus de réflexion.

[Gloops]

Généralement mes noms de table commencent par tab.
Il arrive que certaines tables ne fassent pas l'objet d'une liaison,
leur nom pourra alors commencer plutôt par tbl. Comme ça, on parcourt
toutes les tables, mais on ne met à jour les liaisons que de celles dont
le nom commence par le préfixe idoine.

Ne pas oublier qu'il existe des tables système, dont le nom commence par
Sys, qui par défaut ne sont pas visibles dans l'interface utilisateur,
mais qui font partie de la collection Database.TableDefs
Donc on n'y coupera pas, il faut parcourir la collection des tables, et
pour chacune effectuer un test pour savoir si elle doit faire l'objet du
traitement.

For Each Tb in CurrentDb().TableDefs
If Left$(Tb.Name, 3) <> "Sys" Then
Debug.Print Tb.Name
End If
Next

[John]

"Gloops" :

>>>> pourquoi plusieurs bases ?
>>

>>> C'est la fa�on habituelle de travailler :

>>> - �a facilite les mises � jour, car on peut modifier le code sans
>>> toucher aux donn�es
>>
>> Oui, ca c'est une (tr�s bonne) bonne raison.
>
> N'est-ce pas ?
>
> Dans l'interface utilisateur il existe un gestionnaire de tables li�es,
> pour changer la base source pour toutes les tables � la fois. Cela �tant
> dit, concr�tement, on ne va pas aller tous les mois derri�re l'�paule de
> chaque utilisateur, pour lui dire il faut cliquer l�, non non l�, oui,
> puis l�, et ensuite l� ...
>
> Donc, dans la proc�dure de mise � jour du code, on va introduire une
> fonction de mise � jour des liens, table li�e par table li�e. On trouve �a
> tout pr�t sur Internet, au besoin.

>
>>> - �a all�ge le trafic sur le r�seau, car il n'y a que les donn�es qui

>>> passent -� condition de mettre un exemplaire de la base frontale sur

>>> le poste de chaque utilisateur.
>>

>> Voil� peut-�tre un drawback : lors d'une mise � jour de
>> la base frontale il faut veiller � ce que tout le monde soit ok,
>> ( mais ce n'est pas r�dhibitoire )
>> alors qu'avec un seul fichier, tout est forc�ment � jour.
>
> Pas dur, �a. Dans la table de param�tres on peut tr�s bien mettre un champ
> avec date et heure de mise � jour du code. A chaque chargement, la base
> frontale lit �a, et comme elle sait quand elle a �t� cr��e, si la date de
> mise � jour est plus r�cente :
> - je dis � l'utilisateur que je ne suis pas � jour
> - je d�clenche le t�l�chargement
> - j'indique � l'utilisateur o� il faut cliquer
> - je vais me coucher parce que tout �a m'a bien fatigu� :)
>
> C'est le principe, on peut affiner plus la proc�dure de mise � jour.

>
>>> Entre les deux, le lien se fait en g�n�ral par les tables li�es, qui
>>> au demeurant servent � �a.
>>
>>> D'ailleurs, je me demande bien comment on peut travailler � plusieurs
>>> sur la m�me base, si l'interface est dans le m�me fichier, donc par
>>> voie de cons�quence sur la m�me machine.
>>
>> D'o� une de mes questions d'un post pr�c�dent :
>> si deux utilisateurs, depuis leurs machines A et B en r�seau,
>> ouvrent une base ACCDB situ�e sur une 3e machine C en r�seau,
>> quels sont les �l�ments de la base C (donn�es des tables, etc)

>> qui sont transf�r�s et/ou synchronis�s vers A et B

>> et quels sont ceux qui restent sur C ?
>

> Pas dur, on cr�e des tables li�es vers toutes les tables de la base C,
> comme �a on dispose de toutes les donn�es. Si une table n'a pas � �tre
> mise � jour, on ne cr�e pas d'interface utilisateur qui la modifie.
>
> La table des param�tres (ou des options) est un cas particulier : on met �
> jour champ par champ, sur demande, et toujours sur le m�me enregistrement.
> On peut pr�ciser une clef quand m�me, des fois qu'un jour on veuille
> conserver un jeu de param�tres en historique, et en utiliser un autre. �a
> peut arriver, que les param�tres s'ajustent en fonction de quelque chose �
> quoi on n'avait pas pens�.

Ok.

Effectivement je devrais splitter la base "unique"
en une base de donn�es "arri�re" et des interfaces "frontales",
et j'ai aussi not� le coup de "tables li�es" ( je ferai des tests ).

Merci encore pour ton aide pr�cieuse.

[Gloops]

John a écrit, le 19/09/2012 19:34 :
> Ok.
>
> Effectivement je devrais splitter la base "unique"

> en une base de données "arrière" et des interfaces "frontales",
> et j'ai aussi noté le coup de "tables liées" ( je ferai des tests ).
>
> Merci encore pour ton aide précieuse.

Dis si des problèmes se présentent ...