Merge Replication - Conflicts occur when no conflict SHOULD happen RRS feed

  • Question

  • I am a consultant DBA filling in for the DBA who has gone onto new adventures.

    My client has PULL merge replication in place with 18 subscring servers on serveral publications.

    The retention period has been kept very low at 3 days due to the volumne of data that is getting replicated.

    I have come across an issue which is causing my head to hurt, a subscriber creates a record, it gets replicated as an INSERT as we there is an AUDIT table in place which captures the UTC datetime it occurs, eveybody happy at this stage. Just less than 3 days later an UPDATE is carried out to the record, row replicates, still eveybody happy.

    Then four days later (last update: 08/03/2019  02:03:55  new update: 12/03/2019  08:01:33) this is when we get a conflict, in the conflict viewer it states that there was a update at the PUBLISHER and that is the winner, which was the update that was applied at the 08 March @ 02:03:55 and that the looser is the latest update that was carried out by the subscriber on the 12March @ 08:01:33

    I have double-checked all the audit tables across all the servers and they all have same entries, you can see the different update date on the audit record when replication kicks in on each server, but I cannot see a record on the publisher that is causing the conflict to happen, all I can think of is that the retention period is less than the time-difference between the updates, therefore the publisher will always win with an update that is outside of the retention period, or am I being thick?

    Tuesday, March 12, 2019 11:01 AM

All replies

  • Hi BazDunk,

    By default, if a conflict occurs between a Publisher and a Subscriber, the Publisher always wins the conflict. Please use sp_helpmergepublication to find out where these conflict rows are stored. Then you can check the rows in the specified conflict table. Please refer to View Conflict Information for Merge Publications.

    Best Regards,
    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com

    Wednesday, March 13, 2019 5:33 AM
  • This is a long standing bug in merge replication. I normally write code to resolve these phantom conflicts.

    AFAIK Microsoft has only provided work arounds to this bug, not a solution. But you might want to contact PSS for help on this issue as they may have resolved it.

    Wednesday, March 13, 2019 4:00 PM