Without Required Conflict Resolution What Happens (details please) With Merge and P2P Replication

Question

Ok superficially, it looks like the default conflict resolution features offered by Merge replication and Peer-to-peer replication may not be enough for us. So, I ask what would happen if we decided not to use any conflict resolution scheme at.

I have not decided which replication technology we will be using.

Is it even possible to fully remove from our system the conflict resolution capabilities of Merge replication and P2P replication?

What would happen to our database and all its servers?

What advice can you give me?

What do you recommend doing?

Is this a viable alternative for us?

Thanks,

Answer 1

Conflict resolution is built-in to both Merge and P2P replication and cannot be removed.

With Merge, the default conflict resolution for client type subscriptions is first to publisher wins.  With server type subscriptions the default conflict resolutions is based on assigned priority values and changes made at nodes with the highest priority wins the conflict.

With P2P, if p2p_continue_onconflict is set to true, the change that originated at the node with the highest Originator ID wins the conflict.

I would recommend looking at custom resolvers in Merge Replication if you require sophisticated conflict resolution.

There have only been a handful of cases in which I haven't been able to utilize a custom resolver to properly solve a conflict.  In these cases I have opted for outright avoiding the conflicts, either by changing the business logic, or by making the changes remotely.

---

Brandon Williams (blog | linkedin)

Answer 2

In these cases I have opted for outright avoiding the conflicts, either by changing the business logic, or by making the changes remotely.

What do you mean by "making the changes remotely."

Thanks,

Answer 3

On most published articles I have logically partitioned the data by adding a location specific identifier column named LocationID.  Our application is location-aware and knows when it is updating rows belonging to it's location or another location.  In some cases the application will make data changes remotely if it is changing data for another location.  This way, possible conflicts is avoided.

For example, lets say the application at Location 1 is updating data for Location 2.  Instead of making the change locally at the Location 1 server and risking a possible conflict, it connects to the Location 2 server and makes the change there.

I've rarely had to do this but it is 1 way to avoid possible conflicts.

---

Brandon Williams (blog | linkedin)

Answer 4

On most published articles I have logically partitioned the data by adding a location specific identifier column named LocationID.  Our application is location-aware and knows when it is updating rows belonging to it's location or another location.  In some cases the application will make data changes remotely if it is changing data for another location.  This way, possible conflicts is avoided.

For example, lets say the application at Location 1 is updating data for Location 2.  Instead of making the change locally at the Location 1 server and risking a possible conflict, it connects to the Location 2 server and makes the change there.

I've rarely had to do this but it is 1 way to avoid possible conflicts.

Is this automatic or manual.

Thanks,

Answer 5

This is manual in that it requires development work but it happens automatically for us now.

---

Brandon Williams (blog | linkedin)