| Event Information | According to Microsoft:
Cause:
This is a general error that can be raised regardless of whether a database is replicated. In replicated databases, the error is typically raised because primary keys have not been managed appropriately across the topology. In a distributed environment it is essential to ensure that the same value is not inserted into a primary key column or any other unique column at more than one node. Possible causes include the following:
Inserts and updates to a row are occurring at more than one node. Merge replication and updatable subscriptions for transactional replication both provide conflict detection and resolution, but it is still preferable to insert or update a given row at only one node. Peer-to-peer transactional does not provide conflict detection and resolution; it requires that inserts and updates be partitioned.
A row was inserted at a Subscriber that should be read-only. Subscribers to snapshot publications should be treated as read-only, as should Subscribers to transactional publications unless updatable subscriptions or peer-to-peer transactional replication is used.
A table with an identity column is being used, but the column is not managed appropriately.
In merge replication, this error can also occur during an insert into the system table MSmerge_contents; the error raised is similar to: Cannot insert duplicate key row in object MSmerge_contents with unique index ucl1SycContents.
Resolution:
The action required depends on the reason the error was raised:
Inserts and updates to a row are occurring at more than one node.Regardless of the type of replication used, we recommend that you partition inserts and updates whenever possible, because this reduces the processing required for conflict detection and resolution. For peer-to-peer transactional replication, partitioning inserts and updates is required. For more information, see Link Peer-to-Peer Transactional Replication.< |
