Got it working. I changed all the identies in the target database to be No,
as well as removing all the constraints from that database. Fortunately the
target is never written to by anything else. Doesn't 'feel' like the most
elegant solution but it does work, which is the main thing.
fwiw i wrote a script to change the identity values, directly in syscolumns.
I can't see any problem with this? It seems to work fine!
[quoted text, click to view] Paul wrote:
> I've set all the Identity fields as 'Yes (Not for replication)' but
> i don't know how to set all the constraints to be like this also.
> Perhaps i have my terminology mixed up; there are no 'constraints'
> listed for these particular problem tables - the problem 'constraint'
> as the error message says - is actually under the relationships tab.
>
> In any case i can't see how i can change this so it will work? (let
> alone programatically which is what i need ideally).
>
> Paul
>
>
> Hilary Cotter wrote:
>> the simple answer is to make this constraint a not for replication
>> constraint, or don't replicate the DRI.
>>
>>
>> "Paul" <removethisbitthenitspaulyates@hotmail.com> wrote in message
>> news:2msa49FpotnmU1@uni-berlin.de...
>>>> foreign key constraints cause replication not to work
>>>
>>> I've just setup transactional replication. When i push out a
>>> subscription i get errors because it says
>>> "The constraint 'PK__Invoices__123EB7A3' is being referenced by
>>> table 'ExternalTrans', foreign key constraint
>>> 'FK__ExternalT__Invoi__5D2BD0E6'." which in other words seems to
>>> mean that i cant add rows to tables one at a time due to the above
>>> contraint.
>>>
>>> How can i get round this - do i have to remove all the FK
>>> constraints on the subscription database? If so thats just
>>> ridiculous!
>>>
>>> Thanks
>>>
>>> Paul