One possible way to handle this is to put both tables in multimaster
replication but allow changes to table 2 to be made only at site 1. This
can be enforced with a trigger and some sort of site_code.
"Mark Perona" <mperona_at_earthlink.net> wrote in message
news:5111bb05.0307291341.4b6f2e0a_at_posting.google.com...
> I'm trying to setup replication as follows. Table1 will be replicated
> back and forth from site1 and site2 using multi master advanced
> replication. This is done since changes can be made to the table on
> either side. Table2 is replicated from site1 to site2 using a read
> only materialized view. All changes made to Table2 will be made from
> site1. The problem I have is that Table1 has a foreign key decency on
> Table2. Changes to Table1 are being pushed from site1 to site2 and
> changes made to table2 are pulled to site2 using a materialized view
> group. If a record in table1 is pushed from site1 to site2 before a
> new record it references is pulled from site1 then replication will
> fail.
>
> site1 site2
> Table1 <-> Table1
> Table2 -> Table2
Received on Tue Jul 29 2003 - 17:35:42 CDT
