4

I have a SQL Merge Replication over HTTP (Replisapi.dll). I'm not very familiar with the internas of the replication conflict solving because it was always working so far.

Now I have two conflicts in the replication which I can resolve but after a few seconds the same two conflicts appear again.

The looser is the subscriber DB which wants to insert a row which already exists on Publisher. Therefore I get a Primary key Violation error.

Has anybody ever discovered such a conflict which can be resolved in the Conflict Viewer but always appears again? How can I resolve this issue?

4

Primary key conflicts/violations will not be resolved automatically. You will need to manually delete one of the offending rows to get the primary key conflicts from reoccurring on every synchronization.

If you expect primary key conflicts to occur regularly then you may want to consider doing one of the following:

  1. Horizontally partition your data by adding a location specific identifier column and extend the primary key(s) to include this column. Then have subscribers only insert rows belonging to their partition.

  2. Set the Merge article property @compensate_for_errors to true which sends a compensating change to the source replica to undo the failed change when a primary key conflict occurs.

  • Thanks Brandon. I'm affraid that when I delete the Row on the Subscriber that this change (Deletion) will be propagated to the Publisher and finally I lose both rows. Is my assuption wrong? Can I prevent the replication from merging the deletion to the other side? Thanks. – Thomas Zweifel Mar 21 '13 at 9:33
  • Yes, that assumption is wrong, they have different rowguids. You will need to manually delete one of the offending rows. – Brandon Williams Mar 21 '13 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.