Replication

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.

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.

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.

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.

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

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.

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.

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).

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) :

• s_Generation
• s_GUID
• s_Lineage

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.

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.

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.

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.

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)

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

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