RE: How to handle conflicts?



Hi Danny,

Welcome to use MSDN Managed Newsgroup!

Additionally to David's perfect explaination, I would like to excerpt some
answers from KB Q282977 for your reference

===================
- Why do I get a conflict when I synchronize my replicas?
Because more than one replica has updated data in the same record (in the
same column of the same record if you have chosen column-level tracking)
since the last synchronization. Since Access 2000/Jet 4.0 treats data
errors in the same manner that it treats conflicts, other causes could
include violations to the primary key constrictions and newly created
validation rules.

- How can I avoid (or at least minimize) data conflicts?
The best way to minimize conflicts is to keep them from happening in the
first place. An entire book could be written on this topic, but here are a
few examples of ways to avoid or minimize conflicts:
1. Adding new records instead of editing existing ones. For example, when
tracking inventory, rather than keeping a single field that has the
quantity, create a log table that lists the change. This way, when two
different people remove some of the same item, you will not get a conflict
for the two of them editing the same row.
2. Creating smarter synchronization schedules. The general rule is to set
up your synchronization schedule based on the way your application works.
If one replica contains data that another one will need right away, your
application should make the synchronization right away. This avoids
potential conflicts with someone else changing the same record before the
first set of changes has propagated. It will also help you avoid angry
customers who wonder why they just gave someone an address change and why
they have to do it all over again for someone else!

- How does Microsoft Access resolve synchronization conflicts?
In earlier versions, synchronization conflicts were resolved based upon an
algorithm whereby the most often changed copy of a record won. This
algorithm worked, but was unsophisticated and confusing.
Microsoft Jet 4.0 introduces an algorithm whereby replicas in a replica set
are assigned priorities and the highest priority replica wins in the case
of a synchronization conflict. Where priorities are equal, the replica with
the lowest replica ID wins.
Note: The priority-based conflict-resolution algorithm will work in
conjunction with the corresponding Microsoft SQL Server capability when
Microsoft Jet and Microsoft SQL Server replication are used together.
Replicas are assigned a priority, a real number between 0 and 100,
inclusive, when the replica is created. At the time a database is made
replicable, the Design Master's priority is set to 90. The default priority
of additional replicas is 90 percent of the parent replica's priority. You
can easily specify another priority value either by using the Create
Replica dialog box in Access or by using the CreateReplica method in JRO.
Users must have dbAdminister privileges in order to specify that the
priority of a replica be greater than the priority of the replica from
which it is being created. Using the file system to make a copy of a
replica will create a replica with the same properties and priority as the
source replica.
Note: All replicas upgraded from an earlier version of Microsoft Jet are
given an identical priority value of 90. Replicas created through the
MakeReplica method in DAO have a default priority equal to 90 percent of
the parent replica's priority.
===================

Thank you for your patience and cooperation. If you have any questions or
concerns, don't hesitate to let me know. We are always here to be of
assistance!


Sincerely yours,

Michael Cheng
Microsoft Online Partner Support

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

.



Relevant Pages

  • Re: It cant possibly be this easy!
    ... There's only going to be one laptop. ... > The replica should stay on the laptop. ... > that conflicts need to be resolved, i.e., replica A and B contain changes ... >> synchronization worked OK? ...
    (microsoft.public.access.replication)
  • Re: Unexpected problem with synchronisation
    ... the reason I used an unbound form in this particular ... The data on both the replica and the base station will now be ... record level), and involves replica priority. ... You can also create custom conflict resolution rules that treat the ...
    (comp.databases.ms-access)
  • Replication vs. alternative, priority issues, and more
    ... The replication and subsequent synchronization should be as painless as possible for the client, some sort of one-click implementation would be ideal. ... the DB contains information on about 100 cities, towns and villages, these municipalities are the central information point around which the data model is built ... once every few years the client conducts sort of an audit with each municipality and would therefore like to send them their data (partial replica) in advance for updates and review ... Replica priority: By design it's not trivial in a synchronization to get a partial replica to overwrite a record in its parent DB. ...
    (microsoft.public.access.replication)
  • Re: Replication & Synchronizing
    ... IF you had created the replica, then edited the replica, THEN ... But you wouldn't necessary have a conflict reported for resolution ... the one with the higher priority would win the conflict. ... No single replica can synch with two replicas simultaneously. ...
    (microsoft.public.access.replication)
  • Re: Replication vs. alternative, priority issues, and more
    ... client, some sort of one-click implementation would be ideal. ... Once the data is is edited, the replica has to stay in place, and by ... Replica priority: By design it's not trivial in a synchronization ... to get a partial replica to overwrite a record in its parent ...
    (microsoft.public.access.replication)