December 16, 2010 at 5:26 pm
Hi.
I have a setup where all machines run SQL2005. There is a publisher (no users connect to this) and 5 subscribers (using push merge replication)
There is a function in our software that produces a number of records. I believe this function has been run in two offices at the same time.
The end result is that at one subscriber, we have the same bunch of records (they mean exactly the same thing) with the same primary keys, but they have different RowGUID values so replication considers them to be different records. This means that instead of syncronising their values it throws a primary key violation when trying to merge.
(all other subscribers are good - just this one)
I have two potential solutions in mind.
1) Manually edit the RowGUID on this subscriber to make it the same as all the others. I get the impression that this is not possible - or at the least it seems dangerous.
2) I disable all foreign key constrains on the table, then I delete the record from the problem subscriber, get replication to re-create the record with the correct RowGUID, and re-enable the constraints.
Does anybody have any advice regarding this - or a better solution that I haven't thought of. I am particularly interested in whether there is a 'best practice' or 'officially endoresed' method for dealing with a problem like this.
thanks.
December 18, 2010 at 1:05 am
Can you delete the conflicting rows at one of the subscribers? You say that "they mean the same thing" so I assume that it would be safe to delete the conflicting rows at one of the servers.
We also use merge replication (seven subscribers), and occasionally we have the same issues (unique constraint/index/pk violations). If the rows causing the conflict are identical, we simply delete one of them after consulting the users that created them.
December 19, 2010 at 11:22 pm
Yes, that was my first proposed solution. I tried it just now and it seems to have worked very succesfully (I had to disable some constaints on the table before I could delete but that was okay).
Thanks for your reply.
Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply