Il y a beaucoup de confusion sur ce sujet et j'espère que ce message expliquera
à tout le monde exactement pourquoi il est mauvais de bouger ou de copier des
répliquas.Tout d'abord, je commence par dire que la RÉPLICATION est un
outil très efficace qui nous permet de faire des choses qu'il serait autrement
impossible de réaliser. Ce message ne cherche pas à démolir la réplication,
il est plutôt destiner à faire penser les gens qui utilisent la réplication d'une façon
pour laquelle elle ne fut pas conçue... en montrant les raisons pour
lesquelles cela est dangereux pour leur application et leur données.
************************************
Le BUT DE LA RÉPLICATION: Si vous avez deux copies, ou plus, d'une base de
données JET, elles sont considérées identiques à au plus une synchronisation
près. Plusieurs utilisateurs peuvent effectuer un ou des changements sur leur
copie propre, mais à la fin, ils atteindront la "convergence" et leur
résultat sera le même. Le support est pour des utilisateurs connectés, ou
occasionnellement connectés, mais aucunement pour les utilisateurs isolés. La
réplication de Microsoft Jet n'a pas de scénario pour les cas où il n'y a pas
de véritable connexion directe, indirecte, ou par Internet, point..
************************************
DERRIÈRE LE RIDEAU lors d'un DÉPLACEMENT ou d'un COPIE: Chaque fois que Microsoft
Jet ouvre un répliqua, pour quelque raison que ce soit, il y a une
vérification quand au nom de la machine et du chemin actuel. En cas de
modification, le répliqua se voit attribué un nouveau numéro de ReplicaID
(car des fâcheuses conséquences peuvent se produire si deux répliquas différents
possèdent le même numéro de ReplicaID). Ainsi, si vous partez
d'un ensemble de quatre répliquas et que vous en déplacez un, Jet pensera
qu'il y a maintenant cinq répliquas dans l'ensemble.
Ceci s'applique dans
n'importe lequel des scénarios suivants:
1) Copiez le répliqua sur une
disquette que vous utiliserez chez vous ou ailleurs
2) Copiez ou déplacez le fichier depuis DOS ou depuis l'Explorer
3) Déplacez le fichier sur un disque ZIP amovible de sorte que vos
travaillez sur ce fichier à partir de deux machines, à moins que les deux
machines aient exactement le même nom et que le disque soit connu de la même
façon, même si le fichier demeure sur le disque.
4) Envoyez le fichier par
courrier électronique
5) Toute autre façon que vous pouvez imaginer de copier un fichier,
incluant de le télécharger d'Internet ou d'un serveur, etc.
Par contre, cela
ne se produit pas dans les scénarios suivants:
1) Utiliser la méthode MoveReplica du TSI Synchronizer ou depuis le menu de
commandes du Replication Manager
2) Utiliser le Briefcase Reconciler
Maintenant, cette mauvaise façon de
faire est entravée par une bug, une nuisance et par trois problèmes de
conception qui peuvent devenir très critiques et devenir la cause de corruption
ou de pertes de données.
************************************
BUG #1: Il y a un petit bug isolé dans la manipulation de Jet lorsqu'il
gère le changement de ReplicaID pour un répliqua... il n'effectue pas le
ménage sur l'information quand à quel Synchroniser doit gérer le dit
répliqua. Donc, si vous utiliser Jet Synchronizier pour une réplication
par Internet, ou indirecte, et que vous déplacez cette copie déjà gérée
ailleurs, Jet suppose que l'ancien Synchronizer en est toujours le gestionnaire.
Si ce n'est pas le cas, il y a risque de problèmes lors de synchronisations
subséquentes. Si le répliqua est sans gestionnaire, cela n'est pas un
problème, par contre. Ce bug fut confirmé par les gens de Microsoft, mais
comme ce bug ne se produit que dans un scénario non supporté, son importance
ne fut pas jugée suffisante pour risquer une correction lors d'une révision de
service (service release). Une voie d'évitement est de dissocier le répliqua
de son gestionnaire, ou de n'utiliser que des répliquas non gérés.
************************************
NUISANCE #1: À chaque copie ou à chaque déplacement, la liste des
répliquas s'allonge, d'où un désagrément lorsque vous regardez la dite liste
depuis Access Tools|Replication|Synchronize et dans le Replication Manager. Si
vous transférez en va et vient, entre deux ordinateurs, vous vous retrouvez
avec une multitude de répliquas bidon "c:\foo\bar.mdb" dans la
dite liste. Enlever ces items n'est pas trivial: Jet peut éjecter de la liste
un répliqua qu'on désire ouvrir si son répertoire est toujours présent, mais
que le répliqua ne s'y trouve plus, et alors Jet peut propager cette
information lors de synchronisations... mais il faut le faire pour chaque
répliqua bidon... Il y a également d'autres façons, moins parfaites ou moins
efficaces que celle-ci.
************************************
PROBLÈME (par conception) #1: Microsoft Jet 3.5x possède une limite
de 64,000 synchronizers qui peuvent être "connus" par un
répliqua. Ce n'est généralement pas un problème, mais il faut se rappeler
que si vous créez une réplication autrement qu'avec le Synchronizer, alors Jet
crée un synchronizer virtuel, ce qui est très utile pour les synchronisations
par Internet, par exemple. Vous pouvez ainsi vous retrouver avec 64,000
répliquas invalide et cette limite atteinte génère une situation demandant
beaucoup de travail pour être réglé.
************************************
PROBLÈME (par conception) #2: Une erreur de conflit de données se produit
lorsque deux utilisateurs modifient le même enregistrement et seul le répliqua
perdant, sous Jet 3.5, en devient conscient. Par contre, si un répliqua
qui a perdu le conflit a changé de numéro (entre la détection du conflit et
la prochaine synchronisation), ce qui est survient lorsqu'on copie ou déménage
le répliqua, nous perdons une partie de l'information qui se serait autrement
retrouvée dans les tables de conflits. Cette perte de données est évidemment
très sérieuse.
************************************
PROBLÈME (par conception) #3: un Data error se produit lorsque
l'intégrité de la base de données est en cause, comme dans le cas où deux
utilisateurs utilisent la même clé primaire pour un nouvel enregistrement et
essaient alors de se synchroniser. Dans un tel cas, JET cesse la réplication,
si une telle erreur est rencontrée, et d'autres enregistrements ne sont pas
nécessairement synchronisées tant que le data error n'est pas réglé. Il est
difficile de retracer ces Data Error, qui est relié aux répliquas duquel elle
origine, sans parler du cas où ce répliqua n'existe plus... Je ne connais
qu'une poignée de personnes qui furent capables de résoudre ce problème sans
recourir à la solution extrême de dé-repliquer/re-répliquer. Il est
important de se rappeler que les Data Errors bloquent la synchronisation si bien
que ce ne sont pas tous les répliquas qui reçoivent toutes les informations,
vous laissant dans un état d'inconsistance de données. Vous n'avez aucun
contrôle sur l'ordonnancement des opérations lorsque cela se produit.
************************************
CODA: Finalement, ce petit scénario, qui ne fut jamais supporté, n'a
jamais reçu les tests intensifs des autres scénarios. On peut faire des farces
sur les tests que Microsoft fait de ses produits, mais le fait principal c'est
que ce scénario ne fut pas testé et qu'en plus des points relevés ci-dessus
(que j'ai trouvé, identifié et corrigé depuis plusieurs années déjà), il
peut y en avoir encore quelques autres qui demeurent à trouver. Ironiquement,
les gens qui critiquent le plus Microsoft pour les bugs dans leur produits sont
ceux qui passent souvent outre ce simple avertissement.
Pour les
archives, avant que la réplication pour Jet 3.0 ne soit commercialisée, AUCUN
de ces problèmes n'était connu ni compris, NONOBSTANT, j'ai toujours suggéré
de ne jamais copier ou de déplacer un répliqua avec des données, car *je*
suggère ce comportement à chaque fois qu'un façon de faire n'est pas
supportée. En fait, je n'ai jamais créé d'application qui a rencontré
n'importe lequel de ces problèmes. Par contre, j'ai été personnellement
impliqué dans la récupération de plus de 70 différentes applications, dans
les années passées, qui montraient de sérieux problèmes reliés
exclusivement à ce problème. Le coût total des implications est élevé, mais
il existe des gens pour ignorer cet avis.
************************************
Donc, pourquoi ne pas "être comme Mike" :-) et simplement ne pas
essayer de faire des choses qui ne sont pas supportées ni testées,
spécialement lorsque de telles choses sont connues pour avoir créer
d'importants problèmes?
