September 6, 2002 at 1:30 am
had this prob - came right when I resync and reinitialzed the DB
September 6, 2002 at 10:29 am
Since I was just reminded of this thread, I thought I'd post the solution that I discovered, since things have been working for a while now.
The problem had to do with Cascading Deletes. If a relationship with cascading delete is replicated, then when the actual delete happens, the transaction log gets the delete from both tables individually, but when the delete for the parent table occurs on the subscriber, the cascading delete happens there also, so when the delete for the child table comes through the replication stuff, it doesn't find the row. I hope that gnarly and probably grammatically incorrect sentence made sense.
My first solution was to specify in the article for the child table to not include referential integrity in replication. That removes all foreign key relationships for that table.
My second solution was to specify in the offending relationship - "NOT FOR REPLICATION". That would remove just that constraint from replication. A much cleaner and more exact solution.
Since my subscriber is read-only, both of these solutions work fine for me. If you have an updating subscriber, you would need to keep in mind that some of the constraints are not being enforced in the subscribing database.
James C Loesch
James C Loesch
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply