How to handle SQL Merge Replication Conflicts

Question

I have a situation that I am looking for some guidance on.

I have 4 SQL 2008 databases that are syncronized over the internet using merge replication. 1 publisher and 3 subscribers.

Normally records that are entered on a databases are also only updated from that same database and everything works fine. However, sometimes an update is made at the publisher to a record that was created at the subscriber and can cause a conflict if the same record was updated on the subscriber since the last synchronization (usually 60 seconds).

I have used the conflict resolver built into SSMS and that works fine for me (I understand the schema and underlying data). However, I am looking for a solution where an end user (someone in management) can be alerted of a conflict when it happens and resolve the conflict without any intervention from me in a way that they can understand?

What have others done when having to handle replication conflicts?

Answer 1

From Advanced Merge Replication Conflict Detection and Resolution

When using the default conflict resolver and client type subscriptions, the first change written to the Publisher wins the conflict. When using the default conflict resolver and server type subscriptions, priority values are assigned to individual subscribers and changes made at the node with the highest priority wins the conflict.

This behavior occurs by default and no manual intervention is required even if conflicts occur and appear in the Conflict Viewer. The Conflict Viewer merely provides a means to view conflicts that have occurred within the retention period and manually change the outcomes.

If you require conflict resolution behavior not provided by the default resolution mechanism, you have options:

• Microsoft supplied COM-Based Resolvers
• Business logic handler
• COM-based custom resolver
• Custom Stored Procedure Conflict Resolver (Not very useful for Web Sync subscribers)

A business logic handler or custom conflict resolver would provide a means to alert when a conflict occurs and automatically resolve the conflict based on business requirements.

Answer 2

We first implemented the built-in conflict resolver, as you did, but we regularly had multiple replication conflicts to solve manually. We then decided to improve our system by:

• adding a 'last update date' field in each table
• setting 'Microsoft SQL Server DATETIME (Later Wins) Conflict Resolver' as the default conflict resolver in our replication schema

Conflicts went then down to just a few every month, and it was possible to train the user to treat them through the conflicts viewer interface, with three basic rules:

• if two records have been modified, select the newer (I still do not know why these are not treated automatically, but there are a few of them).
• If there is no older one (modified at same time), choose any (quite common 'fake' conflict situation)
• if one record is deleted and the other modified, select the deletion

And that's it.