Replication

[HJ]

Hi all,

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. 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?

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?

3. Is there any replication possibility that merges field changes? (This
maybe a longshot).

Thanks for your attention,

HJ

[David W. Fenton]

"HJ" <hj********@spa mhotmail.com> wrote in
news:41******** *************@d reader9.news.xs 4all.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

[HJ]

Thank you for responding. So for the replication topology I should store the
design master somewhere on the server, create a central (office) replica
that is used and edited by the office users and create notebook replicas
that are being synchronized with the central (office) replica. Then the
database administrator needs to occasionally synchronize the central
(office) replica with the design master.

And for the simultaneous editing of the same field, I will look at the
transactional editing. It may be convenient to store multiple versions of a
certain remarks field in a separate table. Thanks for the tip.

HJ

"David W. Fenton" <dX********@bwa y.net.invalid> wrote in message
news:Xn******** *************** ***********@24. 168.128.74...

"HJ" <hj********@spa mhotmail.com> wrote in
news:41******** *************@d reader9.news.xs 4all.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