Replication Conflict Detection and Resolution

When synchronization occurs after the initial synchronization, changes made to data on one subscriber might conflict with changes made on a different subscriber or on the Publisher. When you create the publication, you assign a resolver to handle these conflicts.

Detecting Conflicts

When synchronization occurs, the Merge Agent that is running on the Publisher detects any data conflicts, and then determines which data is accepted and propagated to other sites based on the resolver associated with the publication.

Microsoft SQL Server 2005 Compact Edition (SQL Server Compact Edition) supports both row-level and column-level tracking when synchronizing with SQL Server 2005 Publishers. When synchronizing with SQL Server 2000 Publishers, SQL Server Compact Edition supports only row-level tracking.

Row-level Tracking in SQL Server Compact Edition

When synchronizing with a SQL Server 2000 Publisher, the SQL Server Compact Edition Database Engine invokes tracking when any row is inserted, updated, or deleted. When conflicts are detected at the row level, changes made to corresponding rows are considered a conflict, regardless of whether the changes are made to the same column. For example, a change is made at the Publisher to the address column of a row, while another change is made at the Subscriber to the phone number column of the corresponding row. With row-level tracking, a conflict is detected because changes were made to the same row.

Note

Even if the SQL Server 2000 Publisher is configured with column-level tracking, SQL Server Compact Edition marks the row as if every column has changed. Column-level tracking is supported only with SQL Server 2005 Publishers.

Using Resolvers

After a conflict is detected, the Merge Agent launches the conflict resolver that is selected for the article. This might be the default resolver, one of the other supplied resolvers, or a custom resolver. The accepted changes are chosen according to the rules of the conflict resolver. SQL Server Compact Edition Subscriber conflicts are always detected, resolved, and logged at the Publisher.

Important

Multiuser access now permits data changes during synchronization. These changes can cause a client-side conflict. Client-side conflicts are detected, but not resolved, at the Subscriber. The conflict will be redetected and resolved at the publisher during the next synchronization. For more information, see Multiuser Access and Synchronization.

Resolvers can use the source of the data change, or the priority value of the Subscriber, to resolve conflicts. For example, the default resolver follows the rule that the changes on the Publisher always override changes on the Subscriber. You can opt to use a different resolver that always favors the changes on the Subscriber over those on the Publisher.

Note

SQL Server Compact Edition clients always have a priority value of 0. Therefore, a resolver based on priority value will not give priority to the changes made on the device.

For more information about conflict detection and resolution, see "Merge Replication Conflict Detection and Resolution" in SQL Server Books Online.

Note

Stored procedure based merge conflict resolvers are not supported by SQL Server Compact Edition subscriptions.

Using Custom Resolvers

Custom Resolvers let add business logic to Replication. A custom resolver is a DLL built in either managed or native code. To be used, the custom resolver must be registered on the Publisher and the server running IIS by using the stored procedure sp_registercustomeresolver. The sp_registercustomeresolver stored procedure includes the is_dotnet_assembly parameter, which you set to true for a resolver built in managed code, or false for a native DLL.

Important   A custom resolver must be registered on the computer that is running IIS in addition to the computer that is running SQL Server.