I am running merge replication and have a case where a single subscriber is constantly throwing conflicts and retrying rows. In the conflict viewer it's showing that the conflicts are all due to constraint violations. Looking deeper into the issue I can see the same row exists at the subscriber and publisher but with different rowguids. The rowguid column is the PK for that table but another column in the table is also marked as a unique index, causing the conflict. The merge agent sees the different rowguid as another column and is trying to resend it but can't because of the unique index. Not sure how things got this way, the only way rows are getting added to this table are from the publisher (the clients don't add any rows). Any ideas how things got out of whack and how to fix it. Should i just update the rowguids at the subscriber? I don't really want to reinitialize but might have to.
This is happening again. I've got about 1000 more conflicts and its because the rowguids are different between the publisher and subscriber. And so for every sync its trying to push those rows down to the subscriber but that row already exists (just has a different rowguid) and its violating a constraint. Do you know why or how the rowguids are getting out or sync? The only place the row should be getting inserted at is the publisher, we never insert these rows at the subscriber. Also now the conflicts appear to be happening at many different subscribers. Is there a query i can run on the conflict tables that will tell be which rows are conflicting with which subscribers?
The rowguids should be readonly. You apparently have a process which is modifying them, or somehow they are being deleted and recreated.
looking for a book on SQL Server 2008 Administration? http://www.amazon.com/Microsoft-Server-2008-Management-Administration/dp/067233044X looking for a book on SQL Server 2008 Full-Text Search? http://www.amazon.com/Pro-Full-Text-Search-Server-2008/dp/1430215941