Synchroniser plusieurs base de donnees access

Bonjour à tous,

Voilà je viens de rencontrer une association qui a un projet de création d'une base de donnée sous (et oui c'est un choix !).
Il ne dispose pas de serveur.
Pas de réseau.
Seulement des postes individuels et ce sur plusieurs site qui ne stocke pas nécessairement les mêmes infos, mais certaines ce recoupent comme par exemple le nom de bénéficiaire, d'actions, etc...
Chacun désire pouvoir travailler indépendamment sur la base de donnée installée sur son poste personnel.

Par contre ils doivent confronter leur base régulièrement, c'est à dire pouvoir synchroniser l'ensemble de ces bases.

Donc plusieurs questions ?
Si l'individu X enregistre un bénéficiaire identifié par un ID unique et modifie des données sur celui-ci comme par exemple maintenant il est aussi sur cette action, il est rentré dans le dispositif à telle date etc...Que ce passera t il au moment de la synchronisation puisque l'ID unique existe peut-être déjà pour un autre bénéficiaire sur un autre poste utilisateur. Conflit ? Comment cela ce gère ? est-ce possible ?
Est-il possible de récupérer uniquement les infos qui ont été modifiées ?

J"ai vu l'idée de replica sur access mais avec des risques de perte de données et des contraintes éventuelles type copier-coller.

Enfin je me demande si c'est possible et dans ce cas quel axe de recherche prendre

Merci de votre aide

Salut,

je dirais que là, ça pue!

Si tu ne peux pas utiliser un identifiant pour retrouver tes données, c'est plutôt mal barré! Il faudrait alors que tuutilise d'autres données pour identifier de manière unique l'enregistrement voulu. Pour une campagne, c'est peut-être moins bloquant, tu peux utiliser le nom de la compagne/action comme clé primaire (ex: "SIDACTION-2009" etc...). Pour les bénéficiaires, c'est plus chiant. Tu vas devoir les rechercher par Nom + Prénom + Adresse. En effet, tu peux avoir 2 homonymes recensés dans ta base; par contre, 2 homonymes qui ont la même adresse, c'est quand même beaucoup plus rare!!
Le seul problème, c'est que si cette personne déménage, et que le but de la manoeuvre est justement de modifier son adresse, tu ne peux pas te baser dessus pour la recherche. Il faudra trouver d'autres champs de recherche, ou procéder par élimination. Par exemple, recherche sur nom + prénom, puis s'il y a plusieurs résultats on filtre avec un 3° critère etc...

Sinon, il y a peut-être une solution qui éviterait tout ce merdier!

Je pense qu'il te faut obligatoirement une base de référence pour centraliser les données. S'il n'y a pas de serveur, il faudra choisir un des postes pour tenir ce rôle.
Puisque tes bases vont être recoupées périodiquement dans une seule base centrale, tu peux prévoir dans tes tables un champ Identifiant, que tu ne renseignes pas à la création dans ta base locale. Au moment de remonter les données dans la base de référence, tous les enregistrements qui n'ont pas ce champ renseigné (=>tous les nouveaux enregistrements), tu leur attribues un nouveau numéro (en utilisant une séquence) dans ta base centrale, après quoi tu pourras redescendre ce numéro d'Id vers les bases annexes pour qu'elles utilisent toutes le même identifiant.
Comme ça, tu pourras utiliser l'Id en local pour tes recherches, et s'il n'existe pas ça signifiera que c'est un nouvel enregistrement. Attention toutefois, il faudra s'assurer que 2 personnes n'ont pas créé le même enregistrement chacun de leur côté au moment d'intégrer les données dans la base centrale.

Voilou, j'espère que ça pourra t'aider..

Si l'envie te prend de travailler, assied-toi et attend qu'elle te passe! (vieux -et faux!- dicton corse)

Merci pour cette réponse effectivement cela à l'air peu pratique et difficile à mettre en place

Bonjour bonjour,

j'ai pensé à autre chose au lieu de mettre une clé primaire auto incrementée si j'utilise par exemple comme clé primaire le nom, prénom,date de naissance et date+heure pour le nouvelle comme clé, je peux déterminer le dernier enregistrement et par conséquence mettre à jour la base et ces réplica
Non ?

Salut,

Oui, effectivement si tu as un champ discriminant (dateNaissance, timestamp...) il peut te servir à composer ta clé primaire et à te dispenser du n° identifiant. Après c'est une question de choix, perso je préfère avoir un champ Identifiant, parce qu'après dans les requêtes c'est toujours moins chiant de faire une jointure sur un champ unique que sur 3 ou 4 champs.

Si l'envie te prend de travailler, assied-toi et attend qu'elle te passe! (vieux -et faux!- dicton corse)

Bonjour,

Oui je suis d'accord avec toi, mais comme je l'ai expliqué dans mon premier message, si je créé un id unique pour chaque bénéficiaire et que une autre personne sur son propre poste fait un enregistrement nouveau, il risque au moment de la synchronisation des bases d'y avoir un conflit, non ?
C'est pour cette raison que j'ai pensé& à faire un identifiant sur plusieurs champs.
Si tu connais bien sur un autre moyen je suis preneur
Merci de ta réponse