Re: Results of Altering Trigger NOT FOR REPLICATION
From: michelle (michelle_at_nospam.com)
Date: 09/30/04
- Next message: Indra: "missing of data in merge replication."
- Previous message: Paul Ibison: "Re: Results of Altering Trigger NOT FOR REPLICATION"
- In reply to: Paul Ibison: "Re: Results of Altering Trigger NOT FOR REPLICATION"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 30 Sep 2004 15:06:14 -0500
Thanks. That's pretty much what MS said. We already had articles for the
audit tables and they are therefore being kept in synch that way. We have
altered the triggers so that they are NOT FOR REPLICATION.
"Paul Ibison" <Paul.Ibison@Pygmalion.Com> wrote in message
news:OE933NypEHA.3396@tk2msftngp13.phx.gbl...
> Michelle,
> altering your triggers and setting them to NOT FOR REPLICATION will mean
> that they won't fire when the data change originates from the
> synchronization process. However sometimes you want the data to be
> consistent between 2 tables eg perhaps you have TableA which has an audit
> trigger to update TableB. In this case the standard way round this is to
set
> the trigger to NFR and replicate both tables. If there is a PK-FK
> relationship at work, you might need to set the FKs to NFR also, because
the
> parent might be processed after the child record.
> HTH,
> Paul Ibison
>
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
- Next message: Indra: "missing of data in merge replication."
- Previous message: Paul Ibison: "Re: Results of Altering Trigger NOT FOR REPLICATION"
- In reply to: Paul Ibison: "Re: Results of Altering Trigger NOT FOR REPLICATION"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
