Merge Replication : Log the "Winning" Row

    General discussion

  • According to this KB

     After a conflict is detected, the Merge Agent launches the conflict resolver specified for the article with a conflict and uses the resolver to determine the conflict winner. The winning row is applied at the Publisher and Subscriber, and the data from the losing row is written to a conflict table.

    Losing row is logged , what if I want to log also the winning row to compare what changes exactly happened ? when I launch conflict viewer , it looks like the viewer shows the winning row as the last image of the row so there could be more changes in the interiem

    Any idea ?


    Saturday, November 16, 2013 3:34 AM

All replies

  • That is correct, the winning row will be applied at the Publisher and Subscriber and the losing row will be written to the conflict tables.  You are also correct that when you launch the conflict viewer, that the winning may have changed between the time the conflict occurred and when you launch the conflict viewer.

    The way I've dealt with this before is to add audit triggers and tables to capture all changes.  You can compare the rowguids from the conflicts with the rowguids in the auditing tables to get a complete history of what has occurred for any given row.

    Another idea is to write a custom conflict resolver which logs both the winning and losing rows.

    I hope this helps.

    Brandon Williams (blog | linkedin)

    Saturday, November 16, 2013 5:40 AM
  • Thanks a lot Brandon

    All your suggestions are on my agenda as a resolution but was wondering if there's something easier.

    I'd feel more comfortable with triggers or even CDC than custom resolver since I did work before with triggers and CDC beside they are isolated from replication subsystem and I don't want to mess a lot with resolver.

    Saturday, November 16, 2013 6:05 AM
  • I agree.  I've found audit triggers and tables to work best for me.

    I have an example here that you can adjust to meet your needs:

    Brandon Williams (blog | linkedin)

    Saturday, November 16, 2013 6:07 AM