Discussion :

[Tchupacabra]

Bonjour à tous et à toutes...

Le but : faire une synchronisation manuel entre 2 petites bases ACCESS.

Le contexte : C'est une association gérant des adhérents....

Le resumé :
1 base bA principale dans un établissement A
1 base bB secondaire dans un autre établissement B

Le problème : Comment mettre à jour bA à partir de bB et éventuellement inversement.... ?

Une idée :
¤ Chaque enregistrement pourrait avoir un champ "Date d'ajout" et "Date de modif"
¤ Un bouton "Exportation" chez B qui générent un fichier texte par exemple et qui l'envois par mail. Ce fichier pourrait contenir tous les enregistrements ajoutés ou modifiés depuis la dernière exportation...
¤ Un bouton "Importation" chez A pour mettre à jour bA à partir du fichier texte...

Qu'en pensez-vous ? C'est faisable pour un novice ?
Et bien sûr.... vous pourriez m'aidez pour l'export/import SVP ????

Merci d'avance

@+

[Arkham46]

salut,

la synchro de deux bases n'est pas une chose facile.
y a les réplicats en standard; c'est une usine à gaz et les bases doivent être en lien direct lors de la synchronisation (donc chacun devrait envoyer la base à l'autre dans ton cas). Je n'ai jamais utiliser ça à part en test alors je ne sais pas si ça marche bien.

Sinon si tu veux programmer une synchro spécifique y a plein de choses à voir :
- Il faut vérifier les ajouts et modifications mais également les suppressions!
Donc il te faut sûrement une table des suppressions, sinon on ne peut pas savoir si un enregistrement présent dans B mais pas dans A a été supprimé de A ou nouvellement créer dans B...
- Et de plus il faut gérer les conflits : que faire si B et A ont modifiés tous les deux un enregistrement depuis la dernière synchro?
- Pour l'import et export vers et depuis un fichier c'est pas très compliqué avec la méthode <docmd.TransferText>
- Pour l'envoi par mail c'est faisable par exemple si tu es sur outlook avec de l'automation (c'est quelque part dans la FAQ je crois)
- Ensuite pour le traitement il faudra sans doute utiliser des recordsets, donc connaître DAO (y a un tutoriel sur le site)

Donc bilan c'est complexe, bon courage.

[marot_r]

Bonjour à tous.

Il se trouve que je travaille actuellement avec une application dont les bases sont répliquées et c'est pas un cadeau.

Oui, l'utilisation des Replicat integrés d'Access est la solution la plus simple à ce problème. Elle prend en charge la synchronisation des données mais aussi la synchronisation de la structure de la base (tables, requètes, indexs, relations, etc...) et grâce au différent type de réplication (Voir l'objet JRO) on peut même utiliser le Web comme site commun.

Hélas elle n'est pas exempte de problème.

1) Même si performante, elle n'est pas d'une fiabilité à toute épreuve.

2) Elle altère la base de façon quasiment irrémédiable. On peut grâce à TSI Unreplicator récupérer une base non repliquée à partir d'une base répliquée mais là aussi ce n'est pas parfais. Cela pose aussi des problèmes de Backup. Un jeu de réplicat est un ensemble inter-relié de bases, un vrai plat de spagetti.

3) On ne peut pas déplacer une base répliquée. La table MSysReplica, visible avec l'option 'afficher les objet cachés' dans une base répliquée, enregistre le chemin complet et n'est pas modifiable. Il faut créer un nouveau réplicat et ensuite détruire l'ancien.

Donc je suggère d'essayer des solutions alternatives :

a) s'assurer que le partage de donnée est absolument indispensable. Si les personnes ne travaille pas sur le même jeu de donnée alors une réplication manuelle est envisageable sans grosse diffilculté. Cela consiste essentiellement à copier les données de l'un dans l'autre sans avoir à se préocuper des conflits. Il suffit juste d'associer un 'auteur' à la donnée.

b) mettre la base en commun sur un serveur. Comme cela c'est la même pour tout le monde et ça evite pas mal de problèmes. Il n'y a plus de réplicat mais une base unique.

Attention toute fois au nombre d'accès concurents. Au delà de 5, c'est risqué d'après tout ce que j'ai lu bien que je n'ai pas personnellement éprouvé de difficulté avec 10 personnes.

c) Utiliser une base prévue pour cela comme ORACLE ou MSSQL. Attention d'après Papy Turbo (Voir son texte 'Developpement professionnel avec Access' sur ce site) il peut y avoir des contraintes de design.

A+