merge replication issue: conflicts that should not be

  • I have got an issue with merge replication conflicts that should not be conflicts.

    We have got a central order administration (publiher) and 58 stores (subsubscribers). The order status can be changed by both the publisher and the subscriber. It used to work fine until we had a network related issue in the cyber centre. There was no network connection between the central publisher and some of the subscribers for a few days. That caused conflicts, of course, but since then there are more conflicts than there should be:

    1) order status is updated at central publisher

    2) order status is replicated to the one subscriber that is not filtered out

    3) order status is updated at subscriber again a few days later

    And now a conflict is detected. My main question is why? I manually checked that the order record was in sink at both sides; and it was.

    My second question has to deal with debugging this issue. The log file replmerge.log has not been written to since the cyber centre issue. I stopped and restarted all merge agents but no luck. There is no (new) log file.

    I also added -Output to the merge agent command line. This creates a detailed log file, but there is not one error reported in it: just that it detected a conflict and resolved it. So this does not help to answer my question either.

    Is there a community member who can help me out?

  • Whats the metadata retention at the publisher?

  • It is using the default value of 14 days

  • FransG (10/18/2011)


    It is using the default value of 14 days

    Thats fine. Assuming you lost connectivity for less than this then this isnt the issue.

    Each row inserted, updated or deleted in the last 14 days will have information in the metadata tables relating the rows lineage. This keeps track of the row version which increments upon each change. I've been through this in depth and it works. The only time i've had issues is where the meta data has expired as this causes conflicts where they werent necessary

    Are you confident there are no nightly processes at the subscriber or publisher databases?

    It may be worth going through the detail of this article as well.

    http://msdn.microsoft.com/en-us/library/ms151749.aspx

  • Thanks for your input. I will go check the metadata.

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply