Friday, March 23, 2012

Rejected Inserts: but key unique

I'm getting some records coming up in the conflict viewer which havn't been
inserted because there is a "Violation of the Unique key constraint". But if
I join the conflict table to the target table on the primary key I get no
result so keyfld in the conflict table is unique. Can anyone explain why it
is being rejected?
all the best
spike
Perhaps there is a unique index or unique constraint that is being voilated,
reather than the PK?
Rgds,
Paul Ibison
|||On Apr 30, 2:50 am, Spike <S...@.discussions.microsoft.com> wrote:
> I'm getting some records coming up in the conflict viewer which havn't been
> inserted because there is a "Violation of the Unique key constraint". But if
> I join the conflict table to the target table on the primary key I get no
> result so keyfld in the conflict table is unique. Can anyone explain why it
> is being rejected?
> all the best
> spike
I've seen this with merge replication in SQL 2005 with client pull
subscriptions, Scenario:
1) Publisher has master record "A" and detail records "1,2" with
foreign key constraint applied
2) Subscriber connects, receives master/detail data, disconnects
3) Publisher side deletes master record "A"
4) Subscriber {disconnected} adds detail records "3,4" for master
"A" {succeeds}
5) Subscriber replicates
This is what happens:
1) Master record "A" delete is processed without conflict
2) A compensating master "A" delete is sent to the subscriber - the
master record is removed from the subscription database
3) Detail record "3,4" inserts are sent up to publisher - they fail
with foreign key constraint error
4) Detail records "3,4" remain orphaned in the subscriber database -
each subsequent attempt to replicate generates a new insert/FK
constraint error - overwriting the old one - and the conflict date/
time is updated
Reinitializing the subscriber will remove the orphaned data from the
subscriber database and you should stop seeing the conflict date/time
update with subsequent replication attempts...

No comments:

Post a Comment