Discussion :

[Kareg]

Bonjour,

Voilà ma problématique : il se trouve que la base de données sur laquelle je travaille concerne pour le moment une zone géographique donnée, mais qu'il me faut prévoir le fait que j'aurai besoin de la même structure de base pour d'autres zones géographiques.
J'ai donc pensé qu'il faudra faire une base de données distincte par zone (par ex.: Nord, Sud, est, Ouest), mais :
1) je ne suis pas sûr que ce soit la meilleure solution
2) si ça l'est, comment faire pour que l'interface d'utilisation lie les 4 bases ? J'ai fait des recherches en ce sens, mais je n'ai rien trouvé qui permette par exemple d'avoir un formulaire Menu Principal où l'on se rendrait au départ et dans lequel il y aurait 4 boutons qui ouvriraient les bases correspondantes...

Merci bcp d'avance, en espérant avoir été suffisamment clair !

Kareg.

[mout1234]

Menu Principal où l'on se rendrait au départ et dans lequel il y aurait 4 boutons qui ouvriraient les bases correspondantes...

Il faut à mon sens coder une gestion d'attaches personnalisée... Mais, avant tout il faut bien détailler les contraintes et objectifs:

• Est-ce qu'un utilisateur doit pouvoir passer d'une région à une autre fréquement?
• Y-a-t-il des traitements qui portent sur plusieurs régions?
• Les bases sont-elles toutes accessibles depuis tous les postes de travail selon le même chemin?
• Comment déploies-tu ton application (installation sur chaque poste?)?

[Demco]

1) je ne suis pas sûr que ce soit la meilleure solution

Pourquoi ne pas tout mettre dans une seule et même base ?

2) si ça l'est, comment faire pour que l'interface d'utilisation lie les 4 bases ?

Tu peux sans problème te connecter à des bases de données Access avec DAO.

J'ai fait des recherches en ce sens, mais je n'ai rien trouvé qui permette par exemple d'avoir un formulaire Menu Principal où l'on se rendrait au départ et dans lequel il y aurait 4 boutons qui ouvriraient les bases correspondantes...

Une simple ShellExecute dont tu trouveras l'utilisation dans la FAQ te permettra de lancer l'exécution d'un .mde donné.

En espérant t'aider.

[Edit : mout1234 plus rapide et plus pertinent !]

[Kareg]

Merci pour vos réponses (ultra) rapides !

Est-ce qu'un utilisateur doit pouvoir passer d'une région à une autre fréquement?
Y-a-t-il des traitements qui portent sur plusieurs régions?

Pourquoi ne pas tout mettre dans une seule et même base ?

Chaque région est bien individualisée, mais nécessite à 95% la même structure de base (tables, formulaires, relations, etc.) pour entrer les données. En fait je ne voyais pas comment tout laisser sur la même base alors qu'il faudrait pouvoir distinguer les régions, mais si c'est possible de faire cela je suis totalement preneur !

Précision : j'avais pensé au formulaire unique en entrée pour des raisons "esthétiques" et de commodités essentiellement, mais ce n'est pas non plus indispensable. Avoir les 4 bases de données consultables "côte à côte" peut aussi convenir, mais serait moins pratique.

Les bases sont-elles toutes accessibles depuis tous les postes de travail selon le même chemin?
Comment déploies-tu ton application (installation sur chaque poste?)?

Pour l'instant je n'ai pas encore déployé l'application, et ne me suis pas encore préoccupé du meilleur procédé à adopter (je préfère régler tous les problèmes qui pourraient se poser en amont, comme celui évoqué dans ce post)... Je n'ai fait qu'une seule base pour l'instant, et celle-ci est accessible par le réseau selon le même chemin, sur chaque poste concerné.

Merci bien !

Kareg.

[Demco]

En fait je ne voyais pas comment tout laisser sur la même base alors qu'il faudrait pouvoir distinguer les régions, mais si c'est possible de faire cela je suis totalement preneur !

En ajoutant une table région déjà, et rajouter des champs régions (clés étrangères) dans la/les tables où c'est nécessaire.

[mout1234]

Je n'ai fait qu'une seule base pour l'instant, et celle-ci est accessible par le réseau selon le même chemin, sur chaque poste concerné.

Pour commencer, je te conseille vivement - d'autant plus dans ton cas - de séparer données et interface...
http://dolphy35.developpez.com/artic...esReseaux/#LII

Ensuite, deux approches majeures me semblent envisageables:
Solution 1:
une seule base de données (une seule dorsale) contenant les données nationales.

• tu pourras si besoin est facilement effectuer des traitements portant sur l'ensemble des données. Par exemple sur l'ensemble des clients...
• Une seule base de données à maintenir (quand tu dois modifier la structure des tables...)
• tu dois prévoir un paramétrage dont tu tiens compte dans les traitements de ton application pour limiter les fonnctionnalités au périmètre de l'utilisateur
• plus d'évolutivité (si tes périmètres géographiques changent...)

Solution 2:autant de bases de données (dorsales) que de périmètres.

• données intrinsèquement isolées, donc pas de filtrage à faire dans les fonctionnalités de l'appli
• la séparation peut faciliter l'archivage...
• limite le nombre d'utilisateurs pour une même base de données (dorsale)
• traitements portant sur l'ensemble plus difficiles
• autant de bases à maintenir (en cas de modification de la structure des tables)

Etablir dynamiquement la liaison:
http://access.developpez.com/faq/?pa...#RetablLienTbl


Pour ma part, je pense que j'irai plutot vers la solution 1, notamment parce qu'elle est la plus évolutive.

[Kareg]

Merci à vous 2 !

J'ai opté pour la solution 1, grâce à vos conseils avisés, mais maintenant je suis de nouveau bloqué (désolé)

Comme l'a indiqué Demco, j'ai créé la table Région, avec un champ Région qui sert de lien dans les tables concernées (il y en a 5), mais maintenant je ne cerne pas où doit se faire le tri, la sélection dans les formulaires...
J'ai donc un formulaire Menu principal, dans lequel il y a 4 boutons amenant vers chacune des régions. Et ces boutons ont pour action "ouvrir un formulaire", ce dernier étant un sous-menu qui sera identique aux 4 régions. C'est dans ce sous-menu que l'on a ensuite accès aux formulaires des tables, par 5 boutons adéquats.

Sachant cela, où doit-on appliquer le tri ? Par intuition j'ai pensé créer un sous-menu par région, mais n'est-ce pas faire la même erreur de jugement que je faisais tout à l'heure ?

Je m'étends mais peut-être que je devrais maitenant poster dans la section VBA Access

Merci encore en tout cas !

Kareg.

[mout1234]

Puisque tu es libre quant à l'architecture générale de ton interface et que les régions disposent de fonctionnalités quasi identiques, pourquoi en effet créer autant de "sous menus" que de régions?

Je te conseille plutôt de paramétrer dans une table la région utilisée (une table locale à ton interface, donc pas dans la dorsale . Ainsi le paramétrage est propre à chaque poste de travail).
Selon la nature d'exploitation de l'application, tu permets à l'utilisateur de changer le paramètre dans un écran dédié ou tu lui demandes de sélectionner la région dans le menu d'accueil.
Ensuite tu fais référence à cette table dans toutes les sources devant être filtrées et le tour est joué .

[Demco]

Puisque tu es libre quant à l'architecture générale de ton interface et que les régions disposent de fonctionnalités quasi identiques, pourquoi en effet créer autant de "sous menus" que de régions?

Je te conseille plutôt de paramétrer dans une table la région utilisée (une table locale à ton interface, donc pas dans la dorsale . Ainsi le paramétrage est propre à chaque poste de travail).
Selon la nature d'exploitation de l'application, tu permets à l'utilisateur de changer le paramètre dans un écran dédié ou tu lui demandes de sélectionner la région dans le menu d'accueil.
Ensuite tu fais référence à cette table dans toutes les sources devant être filtrées et le tour est joué .

Pas mieux !

[mout1234]

Remarque. En complément, il peut être pratique d'écrire une petite fonction en VBA qui retourne le code de la région sélectionnée. En stockant la valeur dans une variable au démarrage et/ou lorsque l'utilisateur change de région.


Pour ma part, je mets ce genre de truc dans une classe représentant l'appli... mais bon .. pour faire simple, tu crées dans un module standard quelque chose du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
Private mCodeRegion as String 'en supposant ici que ta région identifiée par un code alpha
Public function ap_GetRégionEnCours() as string
 ap_GetRégionEnCours = mCodeRégion
End Function

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
'à utiliser pour mémoriser la région en cours
Public sub ap_SetRégionEnCours(Byval sCode as string) 
    mCodeRégion = sCode 
End sub

Tu peux alors utiliser ta fonction n'importe où, par exemple dans une requête:

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM MaTable WHERE CodeRégion = ap_GetRégionEnCours()

Bon dev

[Kareg]

Donc si j'ai bien compris cela suppose que la base soit scindée (je ne l'ai pas encore fait)? et que la table dont vous parlez soit ajoutée dans la base frontale ?

Je n'ai jamais fait de fractionnement de base, donc pour le moment c'est assez flou mais je vais prendre le temps de bien me familiariser, notamment avec le tutoriel dolphy35... en espérant trouver les réponses aux questions éventuelles qui se poseront !

Merci !

Kareg.

[mout1234]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Donc si j'ai bien compris cela suppose que la base soit scindée

On ne le répétera jamais assez, OUI, il est plus qu'utile de scinder la base en deux. D'autant plus dans ce genre d'applications. Ici, cela devient necessaire si tu veux utilser l'astuce de la table locale que je t'ai proposé.

Bon dev

[Kareg]

Je vais encore vous embêter, car j'aurai besoin de quelques indices / conseils (je débute dc je rame) :

Selon la nature d'exploitation de l'application, tu permets à l'utilisateur de changer le paramètre dans un écran dédié ou tu lui demandes de sélectionner la région dans le menu d'accueil.

J'ai opté pour demander à l'utilisateur de sélectionner la région dans le menu d'accueil, mais je n'ai point réussi à avancer sur ce point... J'ai scindé, fait la table "Région", puis mes diverses tentatives se sont soldées par des messages d'erreur, du type "l'action ou méthode n'est pas valide car le formulaire n'est pas lié à une table ou requête"...
Et concernant la fonction VBA, où dois-je la mettre si j'opte pour le choix ds le menu d'accueil ?

Je précise à nouveau qu'il s'agit de ma 1ère BDD, j'ai pas mal potassé ds des bouquins et des tutos, mais là je me sens légèrement dépassé ...

Et toujours merci !

Kareg.

[mout1234]

Tu mets ta table locale comme source de ton formulaire d'accueil
Tu mets une liste déroulante, liée à ton champ de ta table locale

Si tu veux utiliser ma petite fonction, tu mets tout le code que je t'ai fourni dans un nouveau module

Puis tu appelles la procédure Set à partir de l'évènement Aprés Mise à jour de ta liste déroulante.

Quelque chose du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Sub cboCodeRégion_AfterUpdate(...)
    ap_SetRégionEnCours Me!cboCodeRégion
 
End sub

où cboCodeRégion est le nom que tu donnes à ton controle Liste déroulante.

Bon dev

[Kareg]

Encore une question ...

Tu mets ta table locale comme source de ton formulaire d'accueil
Tu mets une liste déroulante, liée à ton champ de ta table locale

Pour ça c'est bon, par contre c'est là que je ne vois pas comment faire :

Ensuite tu fais référence à cette table dans toutes les sources devant être filtrées et le tour est joué

Comment faire référence, puisque la table est locale et que dans le champ source des formulaires il y a déjà une référence ? C'est un code à insérer ?

Merci !!!

Kareg.

[mout1234]

Comment faire référence, puisque la table est locale et que dans le champ source des formulaires il y a déjà une référence ? C'est un code à insérer ?

La source d'un formulaire n'est pas obligatoirement une table. Tu peux y mettre une requête (de préférence) ou directement une instruction SQL.

Bon dev

[Kareg]

Ca ne marche pas, je crois que je vais jeter l'éponge pour le moment
Désolé mais je ne comprends pas, le fait d'avoir une table locale m'empêche de spécifier à quelle région appartiennent les enregistrements de mes formulaires, et je n'ai aucune idée sur la façon de m'y prendre et il me semble que je me suis mal expliqué et/ou que la logique de la chose m'échappe

A + et merci

Kareg.

[mout1234]

Ca ne marche pas, je crois que je vais jeter l'éponge pour le moment
Désolé mais je ne comprends pas, le fait d'avoir une table locale m'empêche de spécifier à quelle région appartiennent les enregistrements de mes formulaires, et je n'ai aucune idée sur la façon de m'y prendre et il me semble que je me suis mal expliqué et/ou que la logique de la chose m'échappe

A + et merci

Kareg.

Ce n'est pas forcément la méthode la plus efficace mais pour faire simple ... tu peux utliser ma ptite fonction

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM MaTable WHERE CodeRégion = ap_GetRégionEnCours()

Sinon un cas classique pourrait être

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT MaTable.* FROM MaTable INNER JOIN tblParametres ON Matable.coderégion = tblParametres.CodeRégion

où Matable est une table que tu souhaites filtrer sur la région en cours et tblParamètres est la table stockant la région.

[Kareg]

En fait après avoir abandonné un temps je reviens à la charge, ça m'énerve de ne pas comprendre ni trouver

Je récapitule la démarche suivie, en pointant les difficultés rencontrées :
(en repartant du départ, et en travaillent sur la base locale)

- création d'une table région, qui s'appelle "Area", dans la base locale. Elle comporte 2 champs, AreaID (en numéroAuto) et AreaName (en texte, pour les 4 régions "Est","Ouest", "Nord" et "Sud").
- dans le menu principal, création d'une liste déroulante ayant pour origine les valeurs des 2 champs de la table "Area". La zone de liste s'appelle "CboAreaID".
- la source du formulaire d'accueil est la table "Area".

Premier problème:
Mon menu d'accueil renvoit vers plusieurs formulaires ; prenons l'exemple de l'un d'entre eux, le formulaire Wells (dont la source est la table "IdWell") : Il contient des enregistrements de puits que je voudrais pouvoir relier à la région à laquelle ils appartiennent. Comment faire pour que les enregistrements soient enregistrés comme appartenant à une région donnée (avant de faire le tri donc?)?
Mon reflexe serait de créer un champ "AreaID" en menu déroulant lié à la table "Area", mais je ne parviens pas à faire le lien entre la table "IDWell" et la table "Area" puisque cette dernière est sur la bdd locale.

Je m'arrête à cette 1ère question, car une réponse éventuelle sera déterminante pour la suite...

A ++

Kareg.

[mout1234]

En fait après avoir abandonné un temps je reviens à la charge, ça m'énerve de ne pas comprendre ni trouver

Je récapitule la démarche suivie, en pointant les difficultés rencontrées :
(en repartant du départ, et en travaillent sur la base locale)

- création d'une table région, qui s'appelle "Area", dans la base locale. Elle comporte 2 champs, AreaID (en numéroAuto) et AreaName (en texte, pour les 4 régions "Est","Ouest", "Nord" et "Sud").
- dans le menu principal, création d'une liste déroulante ayant pour origine les valeurs des 2 champs de la table "Area". La zone de liste s'appelle "CboAreaID".
- la source du formulaire d'accueil est la table "Area".

Premier problème:
Mon menu d'accueil renvoit vers plusieurs formulaires ; prenons l'exemple de l'un d'entre eux, le formulaire Wells (dont la source est la table "IdWell") : Il contient des enregistrements de puits que je voudrais pouvoir relier à la région à laquelle ils appartiennent. Comment faire pour que les enregistrements soient enregistrés comme appartenant à une région donnée (avant de faire le tri donc?)?
Mon reflexe serait de créer un champ "AreaID" en menu déroulant lié à la table "Area", mais je ne parviens pas à faire le lien entre la table "IDWell" et la table "Area" puisque cette dernière est sur la bdd locale.

Je m'arrête à cette 1ère question, car une réponse éventuelle sera déterminante pour la suite...

A ++

Kareg.

Je comprends maintenant pourquoi tu bloques . La table Area est une table de référence des régions, qui doit logiquement être côté données.
Ce que tu dois mettre en local c'est une table de paramètres (qui peut stocker d'autres paramètres propre à l'utilisateur) dans laquelle il n'y aura qu'un et un seul enregistrement. Cette table comporte un champ par paramètre. Dans notre cas, un simple champ AreaID (Numérique / Entier Long). Il recevra la valeur de l'ID de la région sélectionnée par l'utilisateur.

La liste déroulante elle proposera des valeurs en se basant sur ta table AreaID et tes autres sources pourront se référer à une région par une relation avec la table Area.

Ok?