Reinitialization fails due to MSmerge_genhistory content

[Tobin Schuster]

I am having merge reinitializations fail with the
following error message, 'Cannot insert duplicate key row
in object 'MSmerge_genhistory' with unique
index 'unc1MSmerge_genhistory'.'

I am using SQL Server 2000 w/SP3. I have a merge
publication that is republished from multiple subscribers.
All publications are using dynamic filters to limit the
content at each publication. I am also using alternate
sync partners at the republished servers. (a third level
subscriber can connect to any second level publisher that
has the data that matches its filter requirements.)

[Bill Hollinshead [MSFT]]

Hi Tobin,

Sorry, but it would be safest and easiest for you to open a support case
about this. Some of the imagined resolutions and trouble shooting will
involve modifications to merge processes/objects that can be risky (for
example, a manual intervention upon metadata tables such as genhistory can
cause a problem such as this, as well as such modifications being able to
resolve the error<g>). In addition, your topology is complex (which makes
this a difficult troubleshoot via the newsgroup) and it make take some
serious data collection to identify the cause (perhaps including
replication scripts, backups and traces). I wouldn't be surprised if the
error was due to a bug (that is not related to the 7.0 bug that perhaps
misleadingly has similar symptoms).

I'm sort of restating the obvious, but the msmerge_genhistory bcp file may
have duplicated rows (this is likely the case), or, the msmerge_genhistory
table may already have offending rows that are also being BCP'ed in at a
subscriber that is republished (this sounds less likely). A duplicate is as
defined by the unc1MSmerge_genhistory index. Identifying that row (or rows)
will help product support focus upon the problem. Since genhistory rows
(whether in the table or the BCP file) can potentially originate from any
replica, you may want to ensure all the publishers, republishers and
subscribers are at SP3. If you can reproduce this at will (I noticed you
said reinitializationS) then profiler traces may help pinpoint how the
problem was created. Should you decide to open that support case, you may
want to mention my name, or (if I am unavailable immediately, which is very
likely going to be the situation <g>) you can mention to your Support
Professional that he/she may want to take a look at "TomCat IssueID
16827560".

Thanks,

Bill Hollinshead
Microsoft, SQL Server

This posting is provided "AS IS" with no warranties, and confers no
rights. Subscribe to MSDN & use http://msdn.microsoft.com/newsgroups.