October 18, 2011 at 5:29 am
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?
October 18, 2011 at 6:12 am
Whats the metadata retention at the publisher?
October 18, 2011 at 6:16 am
It is using the default value of 14 days
October 18, 2011 at 7:27 am
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.
October 18, 2011 at 9:28 am
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