When working on replication, it is not uncommon to have such conflicts. Typically what happens is the somebody (or something) changed the key column. Replication uses the ROWGUID column, and therefore, imagine this scenario:
Assume that your ROWGUID is different from the primary keys:
1. Data is added to a table
2. Data replicates to the subscribers
3. Data row is deleted from the publisher and replication link removed manually
4. Data re-added via Import/Export data wizard or manually via script
What would typically happen is that while one would manage to keep the primary keys the same, the ROWGUID changes. Therefore, you end up with a PKV on the subscriber because the publisher is trying to replicate data to the subscriber, which already exists.
On the other hand, if the ROWGUID column value was not changed, either the replication meta-data still has the row marked as "deleted", or one ends up in a data conflict.
In most cases that I have seen, replication issues are either due to bad data-cleanup scripts or poor application design.
In this case, it looks as if the data row replicated to the subscriber was deleted at the subscriber instead of at the publisher. So, now, when the row is updated at the publisher, you end up in a conflict - a classic case of an incorrectly written data-cleanup script.
commented on Sep 5 2011 4:54AM