|
|
I've been doing some testing with the replication/ synchronizing tools in
ACCESS.
Here is what i've done.
Ive created a MASTER_DB with a table called TABLE_1 with a field called
FIELD_1. Populated it with the word "MASTER".
Lets say i replicate this DB (called REPLICA_1).
The user who is works on REPLICA_1. Changes the word "MASTER" to
"ADMINISTRATOR".
I go back to the MASTER_DB and SYCHRONIZE.
I've found that ACCESS has just over written "MASTER" with "ADMINISTRATOR".
Should there be a conflict ???? I would expect there to be one as the record
has been changed.
Is there anyway to TRACK the changes that ACCESS make after a synchronize ??
is it possible to SYNCHONISE from more than 1 REPLICA simultaneously?
|
|
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.
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.
Simultaneous replicas: I guess that depends what you mean by
"simultaneous". 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).
On Tue, 21 Oct 2008 20:44:01 -0700, Kai
<Kai[ at ]discussions.microsoft.com> wrote:
[Quoted Text] >I've been doing some testing with the replication/ synchronizing tools in
>ACCESS.
>
>Here is what i've done.
>
>Ive created a MASTER_DB with a table called TABLE_1 with a field called
>FIELD_1. Populated it with the word "MASTER".
>
>Lets say i replicate this DB (called REPLICA_1).
>
>The user who is works on REPLICA_1. Changes the word "MASTER" to
>"ADMINISTRATOR".
>
>
>I go back to the MASTER_DB and SYCHRONIZE.
>
>I've found that ACCESS has just over written "MASTER" with "ADMINISTRATOR".
>
>
>Should there be a conflict ???? I would expect there to be one as the record
>has been changed.
>
>Is there anyway to TRACK the changes that ACCESS make after a synchronize ??
>
>is it possible to SYNCHONISE from more than 1 REPLICA simultaneously?
--
jackmacMACdonald[ at ]telusTELUS.net
remove uppercase letters for true email
http://www.geocities.com/jacksonmacd/ for info on MS Access security
|
|
jacksonmacd <jackMACmacdo0nald[ at ]telus.net> wrote in
news:l36uf492v07eaolhi3ikelg9nr8ppmms6n[ at ]4ax.com:
[Quoted Text] > 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/
|
|
|