About synchronization conflicts

Microsoft Replication Manager

About synchronization conflicts

Conflicts can occur when data changes are made at two or more replicas.

This topic provides reference information about:

Conflict behavior differences in Access

Simultaneous update conflict

Unique key conflict

Table level validation conflict

Update referential integrity constraint conflict

Delete referential integrity constraint conflict

Locking conflict

Foreign key violation conflict

Case sensitivity in replica sets

Conflicts in partial replicas

Resolving conflicts

Conflict behavior differences in Access

In Microsoft Access 95 and 97, there were synchronization conflicts and synchronization errors. Synchronization conflicts occurred when two users updated the same record in two different databases in a replica set. Synchronizing the two databases would succeed, but only one of the two sets of changes would be applied to both databases. Synchronization errors occurred when a change to data in one database in a replica set could not be applied to another database in the replica set because it would violate referential integrity or some other constraint.

In Access 2000, the events that cause synchronization conflicts and errors are both viewed simply as synchronization conflicts. A single mechanism is used to record and resolve the conflicts, making the process much easier. Whenever a conflict occurs, a winning change is selected and applied in all replicas, and the losing change is recorded as a conflict at all replicas. The Conflict Viewer ,the default tool in Access, is used to reconcile and resolve synchronization conflicts.

Return to top

Simultaneous update conflict

A simultaneous update conflict occurs when two replicas both update the same record. The losing record is logged in the conflict table. Learn about tracking changes to your data.

Return to top

Unique key conflict

A unique key conflict can occur in one of the following ways:

  • Two replicas both enter a new record with the same value in a field that is a primary key or has an unique index.

  • The Design Master creates a unique index, and a replica simultaneously adds two or more records with the same key value. When the schema change reaches the first replica with duplicate key records, then the first duplicate key record remains in the base table. Subsequent records are marked for deletion and are written to the conflict table.

Return to top

Table-level validation conflict

A table-level validation conflict occurs when data that breaks a table-level validation rule that restricts the values or types of data that can be entered into a table is entered. If you add a table-level validation rule to the Design Master without determining if any existing data violates the rule, you may encounter a conflict when you synchronize the design changes to the rest of the replica set. In this case, the records are deleted and logged in the conflict table.

Return to top

Update referential integrity conflict

An update referential integrity conflict occurs when the primary key is updated at one replica and new child records that reference the original primary key value are added at a different replica.

Return to top

Delete referential integrity conflict

A delete referential integrity conflict occurs when a primary key record is deleted in one replica while new child records that reference the deleted primary key are added at a second replica. When the two replicas are synchronized, the new child records are marked for deletion and added to the conflict table.

Return to top

Locking conflict

A locking conflict occurs when the record cannot be applied during synchronization because another user locked the table. Microsoft Access will try to update the record several times, but if unsuccessful, the synchronization will stop, and the entire transaction will return to its original status. An error is returned but no conflict is logged.

Return to top

Foreign key violation conflict

A foreign key violation conflict occurs when there is an invalid primary key record. This could be caused by any of the other conflict types.

Return to top

Case-sensitivity in replica sets

The number of conflicts can increase in replica sets that reside across multiple database types — Access and Microsoft SQL Server for instance — if language sort orders or the case-sensitivity of the sorting is different. This is because unique key values in one database may not be unique in the database with different sorting. The problem can affect both indexed text data and metadata, but it is not an issue for non-indexed text data. Creating replicas with different sorting will require special care to ensure that metadata and indexed text will always be unique for both methods of sorting.

Return to top

Conflicts in partial replicas

A partial replica receives conflicts associated with all of the rows in the partial replica, even for those rows that are added to the partial replica during synchronization.

Return to top

Resolving conflicts

If the same record in a replicated database is changed in one or more replicas, conflicts result when you synchronize a replica with the replica set. When you choose to resolve these conflicts, Access calls the Conflict Viewer. The wizard presents each conflict, and you must manually determine which changed record contains the correct information. How to resolve synchronization conflicts between replica set members.

Return to top