Merge Replication Conflict - Primary Key Constraint

I have an application that uses Merge Replication. In my database design,
before I created the merge replication publication, I modified the tables and
set my identity columns to Yes (Not for replication) option.
I am hitting a problem however, when I try to insert a new row in one of the
tables and then replicate the data back to the server. I am getting a
conflict with the reason being:
Reason Type 5, Reason code 2627
Reason Text:
The row was inserted at Subscriber.x' but could not be inserted at Server.X.
Violation of PRIMARY KEY constraint 'PK_X'. Cannot insert duplicate key in
object X.
I thought that having Not for replication option set for identity columns
would cause replication to use the server and/or subscriber environment to
generate identity column values on inserts.
Any help would be greatly appreciated.
Hi Guy - you'll need to partition the identity ranges to avoid identity
conflicts.
The easiest, most maintainable way is to change the article properties to
enable Automatic identity range management and then reinitialize.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||Thanks Paul. I will try this out and see if the problem is resolved. My
apologies for this message posting so many times. My browser was acting up
and reporting an error when I posted. So I thought my post had failed.
One Question: Do you know why this is happening. I must not be
understanding the purpose of not for replication option. Because I thought
this is what would resolve this type of problem.
"Paul Ibison" wrote:

> Hi Guy - you'll need to partition the identity ranges to avoid identity
> conflicts.
> The easiest, most maintainable way is to change the article properties to
> enable Automatic identity range management and then reinitialize.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com .
>
>
|||The NFT replication allows replication agents to do an identity insert when
distributing changes. However if the renge isn't partitioned, there will
still be a conflict.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .