Discussion :

[manutek]

Bonjour,

Mes cours d'Access sont loin...J'ai commencé à travailler sur un projet Access mais j'ai peur de mal m'orienter dès le départ sur la structure, donc je demande votre avis.

Le projet consiste à la récolte et la compilation de données sur une étude de marché.
Les données seront collectées par des commerciaux itinérants "au fil de l'eau".
Ceux-ci ne devront avoir accès qu'à "leurs" données.
Le directeur commercial doit avoir accès à la totalité des données collectées, ainsi qu'à des requêtes et états de compilation spécifiques.

Mon problème, dans l'idéal, les commerciaux itinérants doivent pouvoir entrer des données en étant "hors ligne". Je me suis donc orienté vers une base par commercial sur leur pc, chacune étant identique en structure et une base (pas encore créée) pour le directeur commercial qui fait des requêtes sur les autres.
Est-ce la bonne solution où je risque d'avoir des problèmes lors de la "compilation des données" car chaque base aura une table "Tiers" avec comme clé "IdTiers" par exemple, mais le IdTiers 0001 correspondra à un client/prospect différent suivant la base?
Ou dois-je étudié les solutions "base dorsale" ?
Ou dois-je ajouter partout dans mes bases "commercial itinérant", un code pour identifié la base dans les clés (qui sont actuellement en n° auto)?

Je vous joins mon graph et relations des tables en PJ.

Un tiers à un secteur (commercial) unique.
Un tiers peu avoir plusieurs fiches "marchés".
Une fiche "marché" est définie par la combinaison d'un tiers+code segment+code application, il ne peut y en avoir 2 avec cette combinaison.
Le code application dépend du code segment (sous-rubrique), mais cette vérité est susceptible d'être modifiée (indépendance des 2 champs).
Un tiers pourra dans le futur avoir qu'un seul et unique code segment, mais là encore c'est pas encore figé
La fiche "marché" est composée de lignes avec des qtés, prix, références et infos techniques.

Voilà, vous savez tout
Merci pour vos conseils.

Manu

[f-leb]

bonjour,

je ne suis pas spécialiste de ce genre de technique mais regarde du côté de la réplication:

Définition de la réplication
La réplication est une technique qui consiste dupliquer une base de donnée pour pouvoir utiliser des copies sur plusieurs postes en même temps. Ainsi, plusieurs personnes sur le réseau peuvent chacun avoir leur copie de la base de donnée sans avoir à ouvrir le même fichier MDB, et récupérer ou envoyer les données supprimées, ajoutées ou modifiées à l’aide d’une synchronisation avec une base commune que l’on place sur un réseau commun aux utilisateurs de cette base de données.

[curt]

Bonsoir,

F-leb, il me semble que la synchronisation n'existe plus dans Access 2010

manutek, je regarde comment contourner le problème.

Curt

[manutek]

Bonjour,

Oui, la réplication de base n'existe plus.

Si je considère que je suis obligé d'avoir une base par commercial, dois-je créé une sorte d'identifiant par base dans toutes les tables la composant?
Par exemple faire un champ "secteur" dans toutes les tables en mettant une valeur par défaut non modifiable en plus des n° auto (clés des tables) et fixer la valeur pour chaque commercial?

Si je décide d'avoir une seule base et que les commerciaux doivent se connecter au vpn pour y avoir accès, est-il facile de gérer l'accès qu'au tiers qu'ils ont créé et à leurs fiches ?

J'ai mis à jour les relations, cf PJ.

Merci de vos lumières et retour d'expérience.

[Richard_35]

Bonjour Manutek, Curt et Fabien,

Tout d'abord, bravo pour ta première approche !

Sur la forme :
Je te suggère de retirer les flèches à gauche (RIGHT JOIN) qui, je trouve, pollue un peu ton MCD (mais c'est juste mon avis). Dans tes requêtes, suivant tes besoins, tu devras alors décider si tu as besoin de flèche à droite ou de flèche à gauche.

Sur le fond :
Tu pourrais créer une même table locale sur la base Access des commerciaux avec un seul enregistrement qui serait :
- Code_commercial (clé primaire sans numéro auto)
- Nom
- Prenom
...

Effectivement, dans ce cas, il faut ajouter le champ Code_commercial à toutes les tables qui sont susceptibles d'être alimentées par les commerciaux et en faire une première clé primaire, en plus de l'actuelle présentée. Les tables contenant des données fixes n'ont pas besoin du code commercial (les données sont entrées en centrale). Il faudra donc coupler toutes les relations.

Notes que Code_commercial pourra être "forcé" en saisie des formulaires avec la valeur qu'il a dans la table locale. Notes, aussi, que l'application reste la même, quelque soit le commercial.

Enfin, dans l'application du directeur commercial, cela semble "être du gâteau" de traiter les tables locales des commerciaux.

[f-leb]

bonjour à tous,

pour info, la réplication a disparu avec le format .accdb apparu depuis la version 2007 d'Access.

Par contre rien n'empêche d'utiliser la réplication avec Access 2007&2010 à condition d'enregistrer la base au format .mdb.

Je me demande même si on ne peut pas utiliser une frontale au format .accdb, une dorsale au format .mdb, dorsale qui serait donc réplicable.

Merci au spécialiste de passage de confirmer que je ne raconte pas de bêtises.