Re: Replication & Synchronizing
- From: "David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx>
- Date: 22 Oct 2008 21:42:02 GMT
jacksonmacd <jackMACmacdo0nald@xxxxxxxxx> wrote in
news:l36uf492v07eaolhi3ikelg9nr8ppmms6n@xxxxxxx:
You describe the correct and expected (at least, once you
understand how it works!!) behaviour. A confict would be created
IF you had created the replica, then edited the replica, THEN
EDITED the master, THEN synchronized. In that case, the single
record would have been edited in both locations prior to
synchronization.
But you wouldn't necessary have a conflict reported for resolution
by the user -- if the replica priority is different between the two
replicas, the one with the higher priority would win the conflict.
So, if you synched between a Design Master (default replica priority
of 100) and a replica created directly from it (default priority of
90% of the parent replica, i.e., 90), then the DM would win the
conflict automatically, and it wouldn't be reported to the user.
Only if the two replicas have the same priority would the conflict
be reported.
And keep in mind that *all conflicts are already resolved* in your
replicas after a synch. When we are "resolving conflicts," what
we're actually doing is checking on Jet's resolution to confirm that
it made the right choice (or not).
Tracking: nothing built-in to Access, and you would have to
develop your own system. Perhaps you could add some columns to
your tables to store the name and date of who made the last
change.
I'm not sure what kind of tracking would be useful. I certainly
stamp the data records in my main tables for creation date, last
update date, and who did the last update, but I do that in all apps,
not just replicated ones. It was a life-saver back in the days when
I was doing replication wrong and was having to manually recover
data from corrupted replicas (back in 1998, before I really
understood best practices).
The main thing about resolution of conflicts is that you understand
how Jet resolves them by default and set your replica priorities
accordingly. If you need something beyond that, then you need to
write your own conflict resolution function. The Access Developers'
Handbook has an example of this. In my 11 years of building
applications with Jet replication I've never once written a custom
conflict resolution function. I *have* constructed custom conflict
resolution forms (to replace the ones Access provides), but only
once.
Simultaneous replicas: I guess that depends what you mean by
"simultaneous".
No single replica can synch with two replicas simultaneously. Well,
let me qualify that: I'd never *try* to do such a thing, because if
it's actually possible, it will cause very complex record and table
locks that could lead to all sorts of problems. One synch could
block the other from completing, for instance. So if I were
scheduling synchs, I'd make sure that no two replicas were synching
simultaneously.
If you're having end users synch, for example, when they shut down
the app on their laptops, you might want to set them up to synch
indirect even when connected directly to the LAN, and use a replica
farm on your synch hub. That would accomplish two major things:
1. Jet would get to process the message files in the drop box
sequentially, which would mean there'd be no contention for locks on
the hub replica, AND
2. Jet could choose whichever replica in your replica farm is
convenient as the target of the synch, which would also relieve
possibilities of conflict between simultaneous synchs should Jet
encounter them.
Nothing to prevent you from editing multiple replicas
at the same time, but you should NOT edit the same record in more
than one replica between synchronizations. Doing so would
constitute a data conflict that you would need to resolve.
By the way, it's considered poor practise to edit the Master
directly. Instead, tuck it away in a safe location and only use
Replicas for data entry. Periodically synchronize with the Master
to keep it from going "stale" (by default, 1000 days before that
happens).
The replica priority issue is one of the main reasons for taking
care of your design master. If you lose your DM and need to recover
it, if you just copy an existing replica, your DM won't have a
replica priority of 100. You may not care about *that*, but then
replicas created from it using the Access UI or the default
synchronize methods will create a new replica that is lower priority
than your other replicas. For example, if you lose your DM and
replace it with a replica that has priority 90, then replicas
created from that new DM will have priority 81, whereas replicas
created from the original DM would have priority 90. That would mean
that conflicts between your 90 replicas and your 81 replica will
always be lost by the 81 replica (i.e., resolved in favor of the
replica with the higher priority), and you'd never be informed about
the conflict (since the Jet rules don't count it as something that
needs to be reported to the user).
Now, if you create your replicas in code, you can set the priority
when you do that. You can also change the priority of a replica
after it's created, but for some reason, those changes are never
recorded in MSysReplicas, with the result that none of the other
replicas know you've changed the priority, and, thus, it won't do
any good in the resolution of conflicts.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.
- References:
- Replication & Synchronizing
- From: Kai
- Re: Replication & Synchronizing
- From: jacksonmacd
- Replication & Synchronizing
- Prev by Date: Re: Replication & Synchronizing
- Next by Date: Cannot set indirect dropbox
- Previous by thread: Re: Replication & Synchronizing
- Next by thread: Cannot set indirect dropbox
- Index(es):
Relevant Pages
|
