March 3, 2016 at 9:20 am
Comments posted to this topic are about the item Resolving merge replication conflicts type 5 & 6
March 24, 2016 at 6:33 am
Thanks for the script and info.
October 31, 2016 at 10:50 am
You're welcome. Looking at the number of views of the script, you are probably one of the very few that actually understand why and when you need this :-D.
I was probably mistaking to think that people know how to resolve "normal" conflicts. I think I will have more readers when I first explain how to properly use conflict viewer to resolve those more normal "2(Column update conflict)" conflicts first. The tool has an abnormal high level of bugs and quirks and it requires considerable knowledge of the user to correctly resolve any conflict. So it is certainly worth some explanation. Maybe if I find the time someday I'll publish an article on that topic. Just out of curiosity to see how many people actually use the tool (and intend to use it properly)...
March 6, 2020 at 4:13 am
Thank you so much. After a lot of searching, I located your script which shades real insight into how to approach this problem.
My case is little reverse though. I have only one subscriber for the publisher. And the subscriber has the updated data for type 5 and 6 (reason mostly 3 and couple of 2601). My users physically moved to the location of the subscriber for practical reasons. As the connection was down during that time, they did not find the update they made at subscriber of the operations they conducted at publisher. So, they did the same activities again in the application connecting to the subscriber. Hence the subscriber data is more recent. Thus, I need to remove the duplicates from the publisher.
Should I delete from the publisher and then submit loser of Type 5(upload insert failed)?
April 11, 2021 at 9:55 pm
@nahid 92520:
Thank you so much. After a lot of searching, I located your script which shades real insight into how to approach this problem.
My case is little reverse though. I have only one subscriber for the publisher. And the subscriber has the updated data for type 5 and 6 (reason mostly 3 and couple of 2601). My users physically moved to the location of the subscriber for practical reasons. As the connection was down during that time, they did not find the update they made at subscriber of the operations they conducted at publisher. So, they did the same activities again in the application connecting to the subscriber. Hence the subscriber data is more recent. Thus, I need to remove the duplicates from the publisher.
Should I delete from the publisher and then submit loser of Type 5(upload insert failed)?
Over a year later you've probably tried it for yourself, but let me still try to answer your question.
When you remove the copy from the publisher to have a subscriber's copy prevail, other subscribers will 'object' to your choice, and every other subscriber's copy will result in a new conflict against your chosen winner: you will have to repeat the same process as many times as you have subscribers. This is because the delete detection mechanism the merge agent applies is not completely correct.
A better way to resolve such a 'reversed conflict' is to update the copy in the publisher db with the values you want to win, then resolve the conflict by removing the subscribers copy and let the publisher's copy win, as described by the script. In your case however -since you only have one subscriber- doing it as you suggested should work just as well.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply