Identity columns

I know a lot of discussion has gone on about identity columns for Merge
replication.

We handle it by just using different identity seeds and increment for
each server (publisher and subscriber) and setting the not for
rpelication to true.

Well, i am now getting tired of having to set this up for our more
customers that are replicating.

We have over 100 tables that have identity columns, but we have a few
that are tied together (meaning chst_id in one table matches cihs_histid
in another table to tie the two together). So, what is the best way to
handle these?

The tables that i don't care about the identity column (it is strickly
used as the primary unique key) i could let SQL handle those (but i am
not too sure how to tell SQL to handle these columns itself), but the
other tables that the two are tied together by an identity column - how
should those be handled?

Darin

*** Sent via Developersdex http://www.developersdex.com ***

Darin,
in the case of chst_id and cihs_histid are both actual identities - I would
have thought that one would be an identity PK and the other a non-identity FK
(or also a PK for a 1:1 relationship). If they are not both identities then
the automatic range management will be fine, but if they are, can you explain
a little more about the architecture.
Cheers,
Paul Ibison, www.replicationanswers.com