Chinese - Simplified   Dutch   English - United States   French   German   Portuguese - Iberian   Spanish  

Home




Usenet Posting #9 - Trigeminal Software, Inc. (English)


Subject: INFO: Clarifying why you cannot illegally move/copy replicas
(Originally posted 4/24/99)
There has been much confusion on this, so the following post will hopefully explain to everyone exactly why it is a bad thing to do this.

Let me start by saying that REPLICATION is damn cool. It lets you do things that there is simply no other way to do. This posting is NOT a flame against replication, it is a flame against people who try to use it in a way it was not designed.... and lays out many of the reasons why the things they are doing are dangerous to their applications and the data herein.

************************************

PURPOSE OF REPLICATION: To have two or more copies of a Jet database that are always considered one synchronization away from being identical. Multiple people can make changes in multiple databases but in the end everyone will reach "convergence" and will be the same. The support is for connected and occasionally connected users... but not FOR disconnected users. Microsoft Jet replication does not support the scenario where you do not have a true direct, indirect, or internet connection. Period.

************************************

MOVE/COPY BACKGROUND: Microsoft Jet, any time it opens a replica (for synchronization, or your app opens it, or whatever) will determine if the replica has been moved. It does this by comparing the path and machine. If it determines that it is not in the same location, it assumes you have copied a replica and it will basically give this replica a new ReplicaID (there are very bad consequences to two replicas with the same ReplicaID). Thus, if you have a Replica Set with four replicas, and you move the location of a replica then open it up.... Jet will think you have FIVE replicas in the replica set.

This will apply in all of the following scenarios:

1) Moving a replica to a floppy and then using the floppy so you can work on the replica at home or at some other location
2) Direct file move/copy in DOS or Explorer
3) Moving a replica via a zip disk so that you are working on it via two different machines/paths..... unless the machine name and path are identical, it will be considered by jet to be a "copy" even if you leave it on the zip disk and synch from there.
4) E-mailing a replica to someone else
5) Any other way you can think of to copy, from downloading from an internet site or file server share, etc.

This will not apply in the following scenarios:

1) Using the built-in methods to move a replica, either via the Replicatuon Manager menu command or the TSI Synchronizer MoveReplica method.
2) The briefcase reconciler

Now, this behavior causes there to be one bug, one annoyance, and three by design problems that are REALLY BAD and can cause corruption and/or data loss.

************************************
BUG #1: There is a single solitary bug in Jet's handling of this "changing the replica ID" stuff.... it does not clean up information on what Synchronizer manages the given replica. So, if you use the Jet Synchronizier for Internet/Indirect replication and you copy a managed replica elsewhere, Jet will make it a new replica but will still think the old Synchronizer is managing it. If it is not, then there can be problems when you try to do synchs and such later. If it was an unmanaged replica, then you will not see any problems at all. This has been confirmed by folks internal to Microsoft to be a problem but since the scenario is unsupported it was not considered important enough to risk a fix in a service release. The workaround is to unmanage, etc. or create a new replica the legal way and then you will have one unmanaged.

************************************
ANNOYANCE #1: As you move/copy these replicas around, the list of replicas will increase over time and you will see more and more replicas appear in (for example) the list of replicas in the Access Tools|Replication|Synchronize dropdrown and in Replication Manager. If you are someone who is copying back and forth between two computers then all of the bogus replicas will be of the same paths.... so you can end up with thousands of "c:\foo\bar.mdb" replicas in the list. Removing these items is not trivial (essentially jet only marks as removed and propogates this info to other replicas if you synch to it and it can find the path but not the file.... so if it can see c:\foo\ but there is no bar.mdb there, it removes it. If you do this 1000 times, you'll remove the thousand entries.). There are other imperfect ways to "remove" bogus replicas that are not as effective as this one.

************************************
BY DESIGN PROBLEM #1: Microsoft Jet 3.5x has a limit of 64,000 synchronizers that are "known" to a replica. Obviously this is not a problem to most applications, but realize that if you do not manage a replica with a synchronizer, then Jet creates a "virtual" synchronizer that you could use to synch with a real synchronizer (very good for internet synchs and such!). This means that as you keep copying, eventually you will have 64,000 invalid replicas, and then you are done, You have screwed up your replica set and you cannot fix it without a lot of work.

************************************
BY DESIGN PROBLEM #2: Data conflicts, which occur when two people update the same row, and reported only in the losing replica for Jet 3.5. Thus if you have a replica that lost a conflict but have (between the time that you entered the data and the time you synch where the conflict is to be reported) moved the replica, remember that it is now a NEW replica, and thus you have lost the data that would have been contained in the conflict tables. This DATA LOSS is obviously very serious.

************************************
BY DESIGN PROBLEM #3: Data errors, which occur when two people affect the integrity of the db (easiest way is when two people put the same primary key in for new records and then synch), are bad. Anytime you synch, Jet assumes that you might have fixed the problems and will "retry" the synch to see if the problem is resolved. If it finds the problem is still there, it stops the synch (and thus no further work happens and no other records are transferred). Since the information reported for a data error is very tied to which replica it came from, etc., it is MUCH harder to track down the cause of a data error when the replica in question is gone... there are only a handful of people I know of who have been able to resolve such situations without going the extreme unreplicate/re-replicate solution. Note that synchronizations are NOT completing entirely when there are data errors... so not all replicas will get all the data, and thus you are in an inconsistent state. You have no control over the order of operations where this occurs.

************************************
CODA: Finally, the entire scenario (since it is not supported) was never given the extensive stress tests that other scenarios were. We may make fun of Microsoft's testing of their products, but the fact is that the stress testing is pretty crucial and having them never have tested it means that in addition to the above issues (which I have been finding, identifying, and fixing for several years now) there may be other issues that have not been found. Ironically, the people who would criticize MS most for bugs in their products will dismiss this complaint.

For the record, before Jet replication ever shipped, for Jet 3.0, NONE of the above problems were known or understood. NEVERTHELESS I always counseled people that you should never copy or move a replica with data in it, ever. The reason is that *I* heeded the above advice where I do not do things unsupported. As such, I have never had an application that I have created hit ANY of these problems. However, I have personally been involved in helping the recovery of over 70 different applications over the last few years that have had serious problems due exclusively to this issue. The total estimated customer cost is HIGH, as people do stubbornly insist on doing this, ignoring the warnings.

************************************
So, why not "Be Like Mike" :-) and just do not try to do things that are unsupported and untested, especially when at this point they have been proven to cause extensive problems?

Back to Usenet Musings


Problems with this site? Please contact the webmaster@trigeminal.com
with your comments, questions, or suggestions.