all groups > sql server replication > october 2005 >
You're in the

sql server replication

group:

Trans Repl- Foreign Key reminders


Trans Repl- Foreign Key reminders Tejas Parikh
10/31/2005 3:45:08 PM
sql server replication:
I was just wondering what are the precautions I should take when trying to
replicate fk's. I know one thing, is that the pk table should be in the same
publication.

Also, default constraints should have no problems, right?
Pk constraints also should have no problems, if I am correct.

On what all things should I set the NOT FOR REPLICATION(only on IDENTITY
values?)
Re: Trans Repl- Foreign Key reminders Hilary Cotter
10/31/2005 11:36:40 PM
This is a complex question. Basically what you must ask yourself is will
there be non replication related DML occurring on your subscriber, and if
so, do you want your PK FK relationships enforced.

If for instance all your DML occurs on your publisher, i.e. no user will
ever do any write activity on your subscriber you don't need to be concerned
about it. If there will be DML activity going on on your subscriber and you
want the pk fk relationships enforced you must replicate the pk and fk (the
include DRI option in the snapshot tab of the table articles property), and
use the NOT FOR REPLICATION attribute.

By default the only constraint which will be replicated is the primary key
constraint, but it will be recreated as a unique constraint on the
subscriber. The only time this will be problematic to you is if the app
using the subscriber database will sniff the schema to ensure the pk is
inplace.

The identity element is only a concern if you are using bi-directional
replication. Consult http://www.simple-talk.com/2005/07/05/replication/ for
more information on identity elements.

--
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html

Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
[quoted text, click to view]

Re: Trans Repl- Foreign Key reminders Tejas Parikh
11/1/2005 8:16:11 AM
Now, this is the situation. I have 2 publications on 1 db. one is
transactional(plain, subscriber-read only) and the other is merge
publication. Also, there is one table which exists in both of these
publications which i think should not be a problem.
Also, when I do merge I want the pk fk relations to be maintained on
subscriber as well since it will be updating the data back to the publisher.
So, I assume, I should include DRI. I'll have to use 'NOT FOR REPLICATION'
for all the contraints. Please tell me if I'm correct. Should i uncheck or
leave it checked the box for 'non-clustered indexes'?
thank you.

AddThis Social Bookmark Button