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] "Tejas Parikh" <TejasParikh@discussions.microsoft.com> wrote in message
news:B8226433-60BA-4E11-98AA-0D86C904CC76@microsoft.com...
> 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?)
> Please let me know anything else I should consider. thank you.