Re: Trigger in Oracle 7.3

Another solution is to use a hidden field that indicates the source of an update/insert/delete, trigger_flag char(1). Leave this field blank when the update, insert or delete is originating from a normal transaction. Set this field to 'Y' when the trigger is generating DML for a synchronized table. A simple check on :new.trigger_flag can be used within the trigger to prevent pinging between tables, .i.e. if the trigger flag is Y do nothing.

What about replication?? Have you tried manipulating replication settings? It might require that you run multiple instances, but it would be worth the ease of management.

Christopher Weiss
Professional Services Division
Compuware Corporation

Clemens Hoffmann wrote in message <7hh8gd$5pl$1_at_linus.heeg.de>...
>Hi there,
>
>we have two database schema that cannot be merged but whose
>contents has to be in sync for some tables in each schema. Some
>tables refer records in tables that have to be in sync. Some
>references are from tables that are local to a schema. A record
>can only be deleted when no record in another table refers to
>the record
>
>We have solved the situation in using database trigger that
>handle the data syncronisation. We classified the trigger
>to be able to create the triggers from seperate trigger tables
>we manage ourself. For our solution we have two opinions:
>
>- Use one trigger for each table that handles insert, update and
> delete for the data sync and the referenc counting on refered
> data record.
>
>- Use one trigger for each operation which means six
> trigger for each table.
>
>Does anybody has experience which is more performant
>or if one of the solution may create problems. We have to
>hold 18 tables in sync.
>
>Greetings
>
> Clemens
>
>
Received on Fri May 14 1999 - 10:32:20 CDT