Starting with Access 95, Jet (version 3.0) introduced a powerful new technology: replication. Put
simply, it allowed you to make 'special copies' of a database such that you could make changes to each copy
so that they would differ and then synchronize them so that they would once again be the same. The founding
architectural principle is that replicas in the same replica set should be thought of as being 'one
synchronization away from being identical.'
At this point, you might want to object that this was not completely true -- after all there are local
objects. And then starting with Access 97 came partial replication. But neither of these things affect the
basic premise, they simply limit the scope of what will be identical. Even the ability to do one-way
synchronizations does not change the premise -- because after a one-way synchronization you were simply
one half of a sync away from being identical!
Underlying all of this was an even simpler principle. You see, since every replica is just one sync away
from being identical, it means that while each replica in unique, none of them really matters! The only
replicas that have any importance are:
- The design master, which allows you to make design changes to the replica set that other replicas will
pick up on future synchronizations, and is not important until such design changes exist (since in its absence
any replica can be promoted to the design master)
- Replicas that contain data changes, which are important until they synchronize (after which they are
identical again and are not important)
In fact, this is the very principle upon which replica farms
are based; since three replicas managed by the same synchronizer are basically identical, Jet can (and does)
use arbitrary means to pick a base replica and has no problems changing replicas any time it has problems.
This is what leads to the problem, though. In Jet 4.0 (used by Access 2000 and 2002), two new replica
types were created to supplement the 'global replicas' that had always existed:
- Local Replicas -- replicas that can only synchronize with a particular global replica, which acts
as a proxy to the rest of the set;
- Anonymous Replicas -- A step beyond local replicas, their existence is not even known to the global
replica that it syncs with.
(for more information, look for the definition of local and anonymous replicas in the article
Database
Replication in Microsoft Jet 4.0 by
Debra Dove)
If you think of replicas in terms of a family metaphor, then local replicas are children who have never met
(and never will meet) their grandparents, and anonymous replicas are children who even their own parents do
not remember -- though they will speak to these strangers who identify themselves as long lost children! Now
think about this analogy for a moment and you will start to see the first problem with these two replica types
with the way that they shatter an important sense of how replication is to work. Although no one should ever
be afraid of invalidating one of my metaphors (<g>), one should pause before dropping an important
philosophical basis for many replication topologies.
This quickly leads in to the next problem: the local and anonymous replicas are only able to sync with
a single replica -- their hub. If their hub fails for some reason, then they are permanently cut off from the
replica set, forever. Jet did not provide a method to change the global replica that would act as a proxy, so
you cannot (for example) count on a replica farm to help you anymore with synchronization stability.
Any time there is a problem and that global replica cannot be reached for a moment, then the poor local or
anonymous replica is permanently cut off! And these problems are not uncommon (which is why replica
farms are so darn useful!). In any real world replication scenario, this guarantees a degree of fragility
for which no customer or user should ever wish.
From here comes the WORST problem: there are numerous cases reported with runtime error 3709, "The
search key was not found in any record" (a.k.a. reserved error '-1601') related to local and anonymous
replicas. Usually, this is a bug; in fact, Microsoft fixed such a bug without directly reporting the fix in
Service Pack 5 of
Jet 4.0. However, in other cases it is simply what happens if a hub replica is invalidated, because after that
happens, Jet is trying to find the replica to synchronize with after disallowing all replicas! In other words,
it is caused by the very design problem that was the cause of this article!
Now, perhaps Jet could do something to fix this: they could support a method to change the global
replica that is acting as the proxy for the anonymous or local replica. Unfortunately, Microsoft has stated
that there will not be future updates to Jet. So unless that policy changes, then it is not possible
to ever see any such change. Also, even if they do decide to release another service pack (and in fairness
they did remove the text from Q239114 that stated there would not ever be such an update!), it is unclear
whether they will consider this to be a blocking bug that requires a fix, versus a design limitation that
cannot be addressed.
Until such a time, the only conclusion that is clear here is that sometimes it does not pay to be
anonymous. Heck, sometimes it does not even pay to be local! Jet replication is such a case, for now at
least. Don't be tempted by these attractive sounding replica types that really cannot add much beyond misery
and frustration to your replication experience.
