Paramétrage d'une application complexe

Bonjour,

J'ai une application ACCESS avec des rubans personnalisés en fonction des profils utilisateurs, un affichage formulaires à onglets, etc, etc (encore un grand merci à tous ceux d'ici qui m'ont permis d'en arriver là !).

Outre mes 70 formulaires vraiment élaborés, je me retrouve avec de plus en plus de micro-formulaires ouverts en mode continus - ou encore plus simplement en mode feuille de données - pour gérer mes diverses tables de paramétrages (des petites listes annexes de 5 à 20 éléments qui recensent divers trucs comme des listes de laboratoires, de types d'évènements, de natures d'objets, etc).

Dans un premier temps, j'avais proposé une ouverture de la base en mode super-admin (cf. appui sur Shift au démarrage) suivi d'une édition directe des tables en question ... mais je commence à douter.

Y a-t'il une façon de s'y prendre pour gérer de telles micro-tables (pour administrateurs et superviseurs seulement) sans avoir à chaque fois à définir une icône dans le(s) ruban(s), à créer un formulaire avec son Form_Open qui maintient le ruban courant et un fonction (appellée par le onAction=".." du ruban) qui ouvrira ce formulaire en mode acFormDS ? Idéalement, j'aimerais avoir un seul formulaire avec une liste déroulante (liste des noms des seules tables concernées) et, dedans, un sous-formulaire en mode feuille de données qui montrerait la table choisie et permettrait de l'éditer sans contrainte particulière.

Cordialement,

Salut!

J'essaie de distribuer une appli qui comporte un paramétrage également.
Ma solution, si tu peux l'adapter:
. une table avec 2 colonnes qui comporte les paramétrages Colonne Sujet | Colonne paramètre.
. Cette table est modifiable dans un menu "Paramètres" qui fait apparaître un formulaire Paramètres
. Un formulaire "Assistant paramétrage" avec des onglets pour chaque sujet et un bouton "Suivant" permettant de passer à l'onglet sujet suivant
. Une ligne particulière dans cette table "Paramètres" mentionnant Colonne Sujet: Assistant param | Colonne paramètre : OUI

Sur le formulaire de démarrage (au premier lancement):
. Une recherche dans la table Paramètres pour savoir si la ligne est à OUI => Lance L'assistant Paramètres => SQL Passant à NON dans les paramètres le lancement pour le prochain démarrage.

J'espère que j'ai été clair dans ma description :weird:

Bonne journée.

Super ! Merci !

Je n'ai pas tout compris mais ça m'a donné la piste : un seul formulaire maître (accessible aux seuls administrateurs), une zone à onglets dessous et un onglet par table de paramétrage (chaque table apparaissant dans un sous-formulaire affichée en mode feuille de données). En plus, cela récupère bien les listes déroulantes et autres formatages spécifiques des tables initiales - Nickel !

... et, dans chaque onglet, je peux ajouter une zone de texte où j'expliquerai à quoi servent les paramètres ci-dessous et ce qu'il faut éventuellement faire pour leur "mise en production effective".

Encore merci !

Bonjour.

Personnellement j'en suis arrivé à la table de paramétrage suivante :

tblParam

Clef (autonum)
CodeGroupe (texte 255 carcatères)
CodeSousGroupe (texte 255 carcatères)
CodeSousSousGroupe (texte 255 carcatères)
Code (texte 255 carcatères) 'Le code paramètres lui-même
Desc (texte 255 carcatères) 'La description
Remaque (mémo) 'Une explication ou autre information utile sur ce que doit contenir ce paramètre et comment
CodeUsager (texte 255 carcatères) 'Dés fois que j'ai un paramètre par utilisateur comme la source habituelle de ses fichiers.
ValeurTexte (texte 255 carcatères)
ValeurMemo (mémo)
ValeurReel (réel double)
ValeurEntier (entier long)
ValeurDate (date/heure)
ValeurBooleen (oui/non)

Avec un index unique sur CodeGroupe, CodeSousGroupe, CodeSousSousGroupe, Code, CodeUsager.

Ça c'est ma table générale et elle couvre pas mal tous mes besoins.
Si je souhaites rendre la saisie plus "amicale", je fais un formulaire qui n'en présente qu'une sélection en changeant les étiquettes des champs.
Par exemple ValeurMemo devient "Chemin Fichier" et ValeurTexte devient "Nom Fichier" ce qui est plus parlant pour mon utilisateur.
Un des défaut majeur est que d'avoir une relation avec l'intégritré référentielle avec cette table est quasiment impossible.

Aussi tu pourrais faire un formulaire qui affiche une liste déroulante de tout tes formulaires disponibles pour les paramètres.

L'utiliateur ouvre le formulaire et choisi dans la liste celui des écrans qui l'intéresse : un seul point d'accès, X formulaire accessibles.

Il me semble qu'on peut mettre des listes déroulantes dans le ruban donc on peut peut-être se passer de formulaire.

A+

Ok, je comprends mieux nos différences de point de vue !

Tu désires stocker des paramètres individuels : une liste bien documentée de couples variable/valeur.

Moi, je gère plutôt des mini-tables qui servent de contenu de listes déroulantes et/ou de références pour diverses requêtes.

Par exemple, chaque "client" peut assumer un "rôle" choisi dans une liste. Comme chaque rôle peut avoir des conséquences différentes en fonction de "domaines", j'ai une table t_RoleClients avec une ID, le nom du rôle et une colonne (boolean) par domaine qui précise si ce rôle est "actif" - ou pas - dans le domaine considéré (la liste des colonnes et donc des domaines est figée, il faut pas exagérer dans la paramétrabilité). Je souhaite donner accès à cette table - et à dix autres du même style - à un administrateur averti pour qu'il vienne ajouter de nouveaux rôles et/ou modifier les coches actif/inactif pour chaque domaine.

Mon formulaire à onglets avec une table en feuille de données par onglet me convient parfaitement. Je suis en train d'ajouter la détection des modifications éventuelles car - parfois - une modification déclenche un besoin de reparcourir toute la BD. Par exemple, si ma table des rôles sert pour un champ multi-valué, et comme on ne peut pas définir de relation d'intégrité référentielle avec effacement en cascade, il faut reparcourir les champs multi-valués, vérifier les options précédemment cochées et faire disparaître toutes celles qui n'existent plus. Bref, on s'éclate !

Cordialement,