Replication

Access 95-97

La réplication permet à deux utilisateurs distants, n'étant pas reliés par un réseau, de malgré tout faire chacun de leur côté des modifications sur une base de données. L'une sera le replica de l'autre. C'est à dire qu'avant de pouvoir utiliser la réplication, il est nécessaire de créer un replica (Outils/Réplication/Créer un réplica). Ca aura pour effet de créer une copie de la base de données telle qu'elle est (tables, requêtes, et les autres objets). Une fois ceci fait, on peut laisser la copie maître à un endroit,et le replica à un autre. Dès ce moment, les deux utilisateurs peuvent chacun de leur côté modifier les données (ajouter, changer, supprimer), mais seul le maître pourra modifier la structure des tables. Lorsque les deux bases de données se rencontrent, on peut les synchroniser (Outils/Réplication/Synchroniser maintenant), et les modifications faire des deux côtés seront mélangées, et les deux bases de données seront alors mises à jour chacune de leur côté.

D'une manière générale, c'est le maître qui aura tout pouvoir par rapport aux réplicas.

Les conflits

Un conflit est généré lorsque 2 personnes changent un même enregistrement de la base de données chacune de leur côté. Par exemple, si X change l'enregistrement "Dupont" en "Dupond", et que, d'autre part, l'autre utilisateur change le même "Dupont" en "Dupons", il y aura un conflit d'écriture qui devra être géré. Cette gestion est proposée lorsqu'on demande la synchronisation des données. Particularité : Si les deux utilisateurs changent chacun de leur côté "Dupont" en "Dupond", aucun conflit n'est généré. Mais attention : S'il existe un conflit, et que l'on demande la synchronisation depuis le maître, AUCUN message d'erreur ne sera généré, et les enregistrements du maître seront épercutés sur le réplica. PAR CONTRE, si on demande la synchronisation depuis un réplica, et qu'il existe des conflits, ils seront indiqués, et, pour chacun d'entre eux, il sera demandé quelle verion on désire garder. Quelles que soient nos réponses, AUCUNE donnée conflictuelle ne sera transférée depuis le réplica vers chez le maître.

Lorsqu'on crée des nouveaux objets, il faut expressément cocher la case Réplicable afin de pouvoir le transférer dans les autres réplicas ou le maître lors de la synchronisation.

Réplication des objets

Admettons que l'on supprime un formulaire d'un maître. Lorsqu'on demande la synchronisation depuis ce maître, le formulaire disparaît également du réplica (étant bien entendu que ce formulaire possède la propriété réplicable (que l'on peut obtenir en cliquant sur le bouton droit de la souris). Lorsque je crée des nouveaux objets dans un réplica, je NE PEUX PAS demander la propriété réplicable.

Lorsqu'on n'est pas dans le maître, il est possible d'entrer dans la structure d'un objet, mais il n'est pas possible de le sauvegarder sous le même nom : Il faut un autre nom. L'objet ainsi résultant ne pourra donc pas avoir la propriété réplicable à oui. Il n'est pas possible d'effacer un objet d'une base de données réplica.

Récupérer un réplica-maître

Cette commande ne s'utilise qu'exceptionnellement, par exemple lorsqu'on a définitivement perdu le maître, ou qu'on change les fichiers de place (auquel cas, le maître devient un réplica qu'il s'agit de retransformer en maître). Dans ce cas, il faut bien pouvoir modifier la structure de la base. ATTENTION : Une fois que l'on a transformé un réplica en maître, on ne peut apparemment plus revenir en arrière.

Cas pratique

Admettons que je livre à X-Inter un programme de facturation. Imaginant aisément que je vais devoir apporter des améliorations diverses tant au niveau des tables que des autres objets, je ne vais donner qu'un réplica, en soulignant bien que :

- Il ne faut pas tenter de le transformer en réplica-maître

- Le client ne peut pas changer la structure des objets, ou, s'il le fait, ceux-ci ne seront pas réplicables, et il faudra alors des copier-coller dans le maître pour pouvoir les utiliser dans les 2 parties

- moi, je ne dois pas supprimer des données de la base, puisque elles seraient ensuite supprimées dans le réplica.

- Je dois également prendre en compte les compteurs incrémentiels, puisque ils seront convertis, lors de la création, en compteurs aléatoires.

Ensuite, je n'ai plus qu'a rapporter la base et à la synchroniser

Multi-réplicas

Il est possible de créer autant de réplicas qu'on désire. Lorsqu'on synchronise deux réplicas entre eux, et qu'il existe un conflit, c'est comme on essayait de synchroniser un réplica depuis ce réplica, vers le maître, C'est à dire que les réglements de conflits ne peuvent pas influer sur l'autre réplica.

Permutation Réplica/Maître

Il est possible, lorsqu'on synchronise un Réplica depuis un réplica avec un maître, de permuter les rôles en cochant la case correspondante qui apparait dans la petite boîte de dialogue de synchronisation. C'est à dire que le réplica devient le maître, et obtient alors ses droits.

Les clés primaires

Attention : Lors de l'établissement de compteurs, lorsqu'on réplique une base de données avec une autre, il est possible, si l'on a de simples compteurs comme clé primaire, que deux tables se retrouvent par hasard avec le même numéroAuto, mais un enregistrement différent (par exemple, si on réplique une base de données contenant une seule table complètement vide, et qu'on installe un seul enregistrement de chaque côté et qu'on réplique, les deux enregistrements possèdent le même numéro : 1).

Pour éviter ce problème, il est possible de donner un numéro de réplication. Ce numéro est absolument unique, et se base apparemment sur des normes internationales, et il serait impossible que par hasard les deux bases Maîtres et Réplica utilisent le même numéro. On peut définir soit un numérique Numéro de réplication, et dans ce cas, c'est à nous de définir un numéro de réplica pour chaque enregistrement, mais c'est donc bien difficile, puisqu'il se présente sous la forme suivante : {00000000-0000-0000-0000-000000000000} (les 0 représentant soit des lettres, soit des chiffres, et les tirets et les accolades devant rester telles quelles). Le plus pratique est donc encore de choisir un type NuméroAuto, et un sous-type N de réplication, ce qui permet à Access de définir lui-même ses propres numéros de réplication.

Les changements visibles lors d'une réplication

D'autre part, lors de la création d'une table réplicable, Access ajoute 3 champs masqués/Système (que nul ne peut modifier) :

Qui sont des champs permettant une réplication correcte.

Concernant s_GUID, si l'utilisateur avait déjà défini un champ N de réplication, s_GUID n'existe pas.

Divers

ATTENTION : J'ai essayé de synchroniser un Maître avec un réplica depuis le maître, alors qu'un enregistrement était en cours de modification dans le réplica, et je n'ai pas eu de message d'erreur, mais évidemment, l'enregistrement en cours n'a pas été pris en compte.

Subtilités de prédominance du maître

Si je suis dans le Maître, et que je remplace Dupon par DuponA, et que je vais dans le réplica, et que je remplace Dupon par DuponB, et que je reviens dans le maître, et que je synchronise, je ne vois pas de conflit, le maître impose sa modification au réplica, et point. Par contre, si, ensuite, je vais dans le réplica, et que je demande la synchronisation avec le maître, alors, à ce moment-là, alors que il paraissait gentiment s'écraser devant les modification du maître, voilà que surgit le conflit, et le réplica a donc la possibilité de revenir à son DuponB, s'il veut, et il restera ainsi différent du maître.

En conclusion, le réplica ne peut jamais avoir de prédominance sur le maître. Il doit toujours être soumis. Le maître qui effectue des modifications, et qui se synchronise avec ses réplicas n'engendre jamais de conflits, c'est toujours lui qui gagne. Mais lorsque ses modifications peuvent altérer les données des réplicas, ceux ci se voient alors créer une table des conflits, résumant les modifications du maître. Ainsi donc, lorsque le réplica, à son tour, essaie de se synchroniser avec le maître, l'assistant des conflits démarre et propose a l'utilisateur du réplica de soit garder les données du maître, auquel cas le conflit disparait, soit de retrouver ses propres données, auquel cas la table des conflits reste en place, et le réplica n'est alors pas la copie exacte du maître.

En réalité, le seul moment ou le réplica peut modifier un enregistrement avec le maître est quand il est le seul à modifier ou supprimer une donnée.

Réplica créé depuis un réplica

Toujours plus subtil : Il est possible de créer un 2ème réplica depuis un réplica. Chacun d'entre eux pouvant alors se synchroniser avec n'importe lequel des deux autres.

Résumé

Je suis dans

Je

Résultat

Je synchronise depuis ou je suis

Maitre

Crée une table, ou un autre objet

OK

La table est créée dans le réplica

Réplica

Crée une table, ou un autre objet

OK, mais sa propriété réplicable n'est pas possible

La table n'est donc pas répliquée

Maitre

Supprime une table

OK

La table est supprimée dans le réplica, même si, entretemps un utilisateur du réplica y avait entré des données

Réplica

Supprime une table

Impossible

 

Maitre

Change la structure d'un objet (table, requête,...)

OK

La structure change

Réplica

Change la structure d'un objet (table, requête,...)

On peut entrer dans la structure et la changer, mais ensuite, il faudra choisir un autre nom pour l'objet. Ce nouvel objet ne pourra ensuite avoir la propriété réplicable

Comme le nouvel objet créé dans le réplica ne peut être réplicable, il ne sera synchronisé nulle part. La seule solution reste le copier-coller.

Maitre

Supprime un enregistrement

OK

Dans le réplica, les enregistrements correspondants sont effacés

Réplica

Supprime un enregistrement

OK

Dans le Maître, les enregistrements correspondants sont effacés

Maître

Modifie un enregistrement, sans conflit

OK

L'enregistrement se met à jour dans le réplica

Réplica

Modifie un enregistrement, sans conflit

OK

L'enregistrement se met à jour dans le maître

Maître

Modifie un enregistrement (avec conflit)

OK

L'enregistrement se met à jour dans le réplica, sans le moindre message d'attention, c'est le maître qui l'emporte

Réplica

Modifie un enregistrement (avec conflit)

OK

Le gestionnaire de conflit s'enclenche, et, à chaque conflit, demande si on veut garder pour ce réplica la version du réplica, ou celle du maître. Quelle que soit la réponse, les changements ne s'effectueront que dans le réplica. De toute façon, dès la prochaine synchronisation du maître, il écrasera les autres.

La réplication partielle

Il est possible de répliquer seulement certaines données de certaines tables. Par exemple, on imagine une base de données centrale, à Genève, et une réplication des données de clients de chaque pays, mais il ne faut pas que les données d'un pays X arrivent par la réplication au pays Y. Il faut donc répliquer la table des clients avec un filtre, par exemple [Pays] = "France" pour que seules soient extraites de la base de données centrale les données des clients "France".

Pour aider à créer une base de données répliquée, il existe un assistant pour Access 97 : le "Partial replica Wizard", non-inclus dans Access 97, mais disttribué gratuitement sur le site de microsoft (wzprtl80.exe)

Marche à suivre :

  1. Télécharger ce fichier, et l'exécuter : Il trouvera automatiquement Access, et s'installera en Add-In
  2. Aller dans Access, et créer ou aller dans une base de données contenant au moins une table réplicable
  3. Faire Outils/Compléments/Partial Replica Wizard, et suivre les instructions de l'assistant

A la fin, on obtient une nouvelle base de données contenant seulement les enregistrements respectant le filtre demandé.

Conflits de filtrage

Que se passe-t-il si le réplica partiel se permet d'entrer un nouvel enregistrement dont le filtre n'est pas correct vis-a-vis du réplica-maître ?

Et bien, ces enregistrements seront répliqués automatiquement dans la base maître. Par contre, comme on s'y attend, un enregistrement créé dans la base maître doit correspondre au filtre demandé pour pouvoir être répliqué avec sa base-fille partielle

La réplication en DAO

La base de données courante est-elle un réplica ?

If CurrentDb().Properties("Replicable") = "T" Then

MsgBox "Base actuelle est réplicable"

Synchronisation

CurrentDb.Synchronize "Allemagne.mdb", dbRepImpExpChanges