Er is veel verwarring geweest hierover, dus hopelijk verklaart de volgende post aan iedereen precies waarom je dit beter niet kunt doen.
Ik wil beginnen met zeggen dat REPLICATIE enorm cool is. Het laat je dingen doen die je niet op een andere manier kunt doen. Deze posting is GEEN flame tegen replicatie, het is een flame tegen mensen die het willen gebruiken zoals het niet bedoeld is... en het zet veel van de redenen op een rijtje waarom de dingen die ze doen gevaarlijk zijn voor hun applicaties en de gegevens daarin.
************************************
DOEL VAN REPLICATIE: twee of meer kopieen hebben van een database die worden geacht steeds een synchronisatie af te zijn van volledige gelijkheid. Meerdere mensen kunnen veranderingen aanbrengen in meerdere databases, maar aan het eind zullen ze alle samenkomen en gelijk zijn. De ondersteuning is aanwezig voor verbonden en af-en-toe verbonden gebruikers... maar NIET voor niet-verbonden gebruikers. Microsoft Jet Replicatie werkt niet als je geen directe, indirecte of internet-verbinding hebt. Punt.
************************************
ACHTERGROND VOOR VERPLAATSEN/KOPIEREN: Elke keer dat Microsoft Jet een replica opent (voor synchronisatie, of je applicatie opent het, of wat dan ook), zal het bepalen of de replica verplaatst is. Dat doet het door het pad en de machine te vergelijken. Als het bepaalt dat de replica zich niet op dezelfde locatie bevindt, neemt het aan dat je een replica hebt gekopieerd en geeft deze in principe een nieuwe ReplicaID (er zijn zeer slechte consequenties voor twee replica's met dezelfde ReplicaID). Als je dus een Replica Set hebt met vier replica's en je verplaatst een replica en opent hem dan... dan denkt Jet dat je VIJF replica's hebt in je set.
Dit is van toepassing in alle volgende situaties:
1) De replica naar een diskette verplaatsen en dan de diskette gebruiken zodat je thuis of op een andere plaats met de replica kunt werken
2) Directe verplaatsing of kopieren in DOS of de Verkenner
3) Een replica verplaatsen via een zip-schijf zodat je via twee verschillende machines/paden er aan werkt... tenzij de naam van de machine en het pad identiek zijn, zal Jet het als een "kopie" beschouwen zelfs als je het op de zip laat staan en van daaruit synchroniseert
4) Een replica naar iemand anders mailen
5) Elke andere manier die je kunt bedenken om te kopieren, downloaden van een internetsite of fileserver enz.
Dit is niet van toepassing in de volgende situaties:
1) De ingebouwde methoden gebruiken om een replica te verplaatsen, via het Replication Manager-menucommando of de TSI Synchronizer MoveReplica-methode
2) De werkmap
Dit gedrag zorgt voor een bug, een irritatie en drie ontwerpproblemen, die HEEL ERG zijn en kunnen zorgen voor corruptie en gegevensverlies.
************************************
BUG #1: Er is een enkele bug in de afhandeling door Jet van dit gedoe met het "wijzigen van de replica ID"... het schoont de informatie niet over welke Synchronizer deze replica beheert. Als je dus de Jet Synchronizer gebruikt voor Internet- of indirecte replicatie en je kopieert een beheerde replica ergens anders heen, dan maakt Jet een nieuwe replica, maar denkt nog steeds dat de oude Synchronizer deze beheert. Als dat niet het geval is, kunnen er problemen optreden als je later synchs en zo wilt doen. Als het een niet-beheerde replica was, zie je helemaal geen problemen. Door lui binnen Microsoft is bevestigd dat dit een probleem is, maar omdat het scenario niet wordt ondersteund, vond men het niet belangrijk genoeg om er een reparatie in een service release aan te wagen. Je kunt eromheen door te "ont-beheren" enz. of door op correcte wijze een nieuwe replica te maken, maar dan heb je een niet-beheerde replica.
************************************
IRRITATIE #1: Als je deze replica's her en der verplaatst/kopieert, zal de lijst met replica's groeien. Je zult steeds meer replica's zien verschijnen in (bijvoorbeeld) de lijst met replica's in het afrolmenu Access|Tools|Replication|Synchronize en in de Replication Manager. Als je iemand bent die heen en weer kopieert tussen twee computers, dan zullen alle nep-replica's hetzelfde pad hebben... je kunt dan uitkomen op duizenden replica's met de naam "c:\foo\bar.mdb" in de lijst. Het is niet eenvoudig deze replica's te verwijderen - in wezen markeert Jet replica's alleen als verwijderd als je synchroniseert, en het kan wel het pad vinden maar niet het bestand... dus als het c:\foo\ vindt, maar geen bar.mdb, dan wordt het verwijderd. Als je dit 1000 keer doet, kun je de duizend ingangen verwijderen. Er zijn ook andere imperfecte manieren om nep-replica's te "verwijderen", maar die zijn minder effectief.
************************************
ONTWERPPROBLEEM #1: Microsoft Jet 3.5x heeft een limiet van 64.000 synchronizers die "bekend" zijn voor een replica. Het is duidelijk dat dit voor de meeste applicaties geen probleem is, maar realiseer je wel dat als je een replica niet beheert met een synchronizer, Jet een "virtuele" synchronizer creeert, die je kunt gebruiken om met een echte synchronizer te synchroniseren (heel goed voor internet-synchs en zo!). Dit betekent dat je, als je blijft kopieren, uiteindelijk 64.000 ongeldige replica's hebt en dan ben je er geweest. Je hebt je replicaset verinneweerd en je kunt het niet oplossen zonder veel werk.
************************************
ONTWERPPROBLEEM #2: Gegevensconflicten, die optreden als twee mensen dezelfde rij bijwerken, en die alleen gerapporteerd worden in de verliezende replica bij Jet 3.5. Als je een replica hebt die een conflict heeft verloren, maar je hebt (tussen het moment van invoeren van de gegevens en het moment van synchroniseren om het conflict te rapporteren) de replica verplaatst, onthoud dan dat dit een NIEUWE replica is. Je bent de gegevens kwijt die in de conflicttabellen stonden. Dit GEGEVENSVERLIES is uiteraard ernstig.
************************************
ONTWERPPROBLEEM #3: Gegevensfouten, die optreden wanneer twee mensen de integriteit van de db aantasten (de eenvoudigste manier is wanneer twee mensen dezelfde primaire sleutel invoeren voor nieuwe records en dan synchroniseren), zijn erg. Elke keer dat je een synch uitvoert, neemt Jet aan dat je de problemen hebt aangepakt en dat je de synch "opnieuw probeert" om te kijken of het probleem is opgelost. Als Jet ontdekt dat het probleem er nog is, stopt het de synch (en dus gebeurt er verder niets en worden geen andere records overgedragen). Omdat de informatie die voor een gegevensfout wordt gerapporteerd samenhangt met van welke replica het kwam, enz., is het VEEL moeilijker om de reden van de gegevensfout te traceren als de betreffende replica verdwenen is... Er zijn maar een paar mensen die ik ken die dergelijke situaties hebben kunnen oplossen zonder hun toevlucht te nemen tot on-repliceren en her-repliceren. Let op: synchronisaties worden NIET afgerond als er gegevensfouten zijn... dus niet alle replica's krijgen alle gegevens, en dus bevind je je in een inconsistente situatie. Je hebt geen controle over de volgorde van handelingen wanneer die optreedt.
************************************
CODA: Ten slotte, dit hele scenario is nooit zo uitgebreid en zwaar getest als andere scenario's, omdat het niet ondersteund wordt. We kunnen wel lachen om de manier waarop Microsoft zijn producten test, maar het blijft een feit dat het zware testen cruciaal is. Dit betekent dat er naast bovenstaande punten (die ik nu al enige jaren heb gevonden, geidentificeerd en gerepareerd) nog andere zaken kunnen zijn die nooit gevonden zijn. Ironisch genoeg zullen de mensen die de meeste kritiek hebben op MS vanwege bugs in hun producten, deze klacht van de hand wijzen.
Even voor de duidelijkheid: voordat Jet-replicatie in productie kwam, voor Jet 3.0, was GEEN van bovenstaande problemen bekend of begrepen. DESALNIETTEMIN geef ik mensen altijd de raad om nooit, maar dan ook nooit een replica met gegevens te kopieren of verplaatsen. De reden is dat *ik* me houd aan bovenstaand advies als ik geen niet-ondersteunde dingen doe. Op deze wijze heb ik nog nooit met een door mij gemaakte applicatie ook maar EEN van deze problemen gehad. Ik ben echter de laatste jaren persoonlijk betrokken geweest bij meer dan 70 verschillende applicaties die puur vanwege dit punt ernstige problemen hadden. De totaal geschatte kosten voor klanten zijn HOOG, omdat mensen koppig dit soort dingen blijven doen en de waarschuwingen negeren.
************************************
Waarom dus niet "Be Like Mike" :-) en probeer gewoon geen dingen te doen die niet ondersteund worden en niet getest zijn, speciaal wanneer bewezen is dat ze op dit punt op grote schaal problemen veroorzaken?
