"HJ" <hj********@spamhotmail.com> wrote in
news:41*********************@dreader9.news.xs4all. nl:
I am looking at a problem we encountered with replication. Our
front-end and back-end are Microsoft Access 2000. We have a design
master at the server and replicas at five notebooks. . ..
Are you having users edit data in the design master? If so, that's a
bad idea -- actively used MDBs can be corrupted, and if you lose the
design master you'll have problems.
Create a replica for the central office users to use, as well, and
synch it only occasionally with the design master (which doesn't
need to have up-to-date data). The design master should be
squirrelled away somewhere safe.
. . . The notebooks
are synchronized daily by the users via a form that uses Microsoft
Jet and Replication Objects (JRO) and this works well.
I have a few questions about this:
1. A problem occurs when two users change the same field in the
same record at the same time. When they synchronize their
replicas, only one 'version' of the field remains. The other one
disappears. I would say that this is a synchronization conflict,
but it does not appear as such. Also when I open a replica or the
design master directly no conflict is being reported. How can I
see which 'version' of the field has been deleted?
The conflict resolution formula is complex, and I don't know if
changes to data in a design master are given priority over changes
in a replica, but it could be that this is the source of your
problem. That is, your incorrect topology may be causing your
problem.
In any event, Jet 4 replication is field-based, but it's still based
on the side with the most changes. That is, if a field in Replica A
has 2 changes and the corresponding replica in Replica B has 1,
Replica A will win the conflict without being reported as a conflict
(all other things being equal). Conflicts are reported only when the
number of changes on both sides are equal.
2. If we would be using SQL Server at the server and MSDE or SQL
Server at the notebooks, will the replication work the same way in
that the entire field is being replaced?
I don't know for certain, but I suspect that SQL Server replication
won't be any better in this regard. But I haven't used it, so can't
say. There was a time when Jet replication had more features that
SQL Server's.
3. Is there any replication possibility that merges field changes?
(This maybe a longshot).
Applications in which single records are being updated in multiple
locations are not good candidates for replication in the first
place. Replication works best when the records edited in different
replicas do not overlap, or are mostly adds/deletes.
It may be that you could restructure your data to use transactional
editing. For instance, if the field that is conflicting is something
like a LAST DATE field, you could move that field into a table where
you record all the dates in order, which won't conflict, because
changes to the LAST DATE are made by adding a new record, not by
editing a field.
That's not the best example, but you get the idea -- with
replication you sometimes have to restructure your data for the
synchronization to work.
--
David W. Fenton
http://www.bway.net/~dfenton
dfenton at bway dot net
http://www.bway.net/~dfassoc 
