sql server replication: Ron
on the article properties you can specify to take DRI. The foreign key constraints are only taken if both tables (PK and FK)are in the same publication. If they are in different publications, when you create the publication containing the FK table, you can specify a post-script - some TSQL which is run after the snapshot is created. This script can apply the FK cascading constraint
Regards

We have a SQL 2k (SP3a) database that we are working on setting up
replication on. Our replication is Merge replication, and we are using a
Push subscription. I just noticed this morning that tables on the Publisher
which are defined as having the "Cascade Updates" flag set do not have the
same flag set on the subscriber. This results in some interesting problems
with the front end application having errors that "magicaly" clear up after
replication occurs. Is there something I need to do in defining the
snapshot to force this flag to be set on the subscriber? When we push the
subscription to the subscriber, we normally start with a brand new database
with all schema definitions coming from the snapshot.

TIA
Ron Lounsbury

Paul
Thanks for the response. I will look into taking the DRI since all the
relevant tables are in the same publication.

Ron Lounsbury


[quoted text, click to view]
constraints are only taken if both tables (PK and FK)are in the same
publication. If they are in different publications, when you create the
publication containing the FK table, you can specify a post-script - some
TSQL which is run after the snapshot is created. This script can apply the
FK cascading constraint.
[quoted text, click to view]

Paul
I just looked at our script for setting up replication, and in the
sp_addmergearticle we are setting the @schema_option to 0x000000000000CFF1.
The last F should take care of the "include referential integrety on the
primary keys" which is 0x80. Is there something I have missed, or some
other place that something needs to be set?

TIA
Ron Lounsbury


[quoted text, click to view]
constraints are only taken if both tables (PK and FK)are in the same
publication. If they are in different publications, when you create the
publication containing the FK table, you can specify a post-script - some
TSQL which is run after the snapshot is created. This script can apply the
FK cascading constraint.
[quoted text, click to view]

Ron,
the schema bitmap looks fine - I use the same and the constraints go across
ok. Do you have the same value on each article? Apart from that there's not
much I can think of! You're using sp3 while the machine I'm on is an
evaluation copy of Sql server (no sps), but I haven't heard of this being a
factor. Perhaps if you do have the same value on each article you could
script it all out (including the tables) and I'll set it up on Monday -
please post it to me or send it to the newsgroup.
Regards,
Paul Ibison

Paul
Boy do I feel dumb. Looking at Enterprise Manager, I missed the
pulldown for the Relationship Name. The relationship was there, it was just
that there was a different default selection on the 2 machines. I guess now
I will have to dig deeper to find out what is going on with my underlying
problem. I was sure that the problem was the lack of cascading updates on
one table on the subscriber - it answered the symptoms so well.

Thanks for the help
Ron Lounsbury

[quoted text, click to view]