Triggers on target tables of any replication deserve special consideration, and Dbvisit Replicate is no exception. The concern is whether triggers defined on the target tables should fire when data changes are applied to the table. This depends on the logic in the trigger and thus has to be decided by the user.
...
Variable APPLY_SET_TRIGGER_FIRE_ONCE can be used to disable or further control this functionality. If APPLY_SET_TRIGGER_FIRE_ONCE is set to YES for the apply process, then on supported versions of Oracle (10.2.0.5 and 11.2.0.2 -11.2.0.3), the triggers do not fire for changes done by the apply process if the "set fire once" property of DBMS_DDL.SET_TRIGGER_FIRING_PROPERTY is set for that triggers (this is the default).
For each trigger the "fire once" property can be changed for each trigger by using DBMS_DDL.SET_TRIGGER_FIRING_PROPERTY.
On every MySQL target, you can check variable @is_dbreplicate_session (valued 0/1) to find out whether it's an APPLY session or not.
On every MS SQL target, you can check context_info to find out whether it's an APPLY session (set to 1) or not.
| Note | ||
|---|---|---|
If triggers that are created separately on the target database are not firing when DML from the Apply process is run against them, then set:
|
...
Add the trigger execution condition as follow. follows:
| No Format |
|---|
create or replace trigger TRG_TEMP before update on SCHEMA.TABLE for each row begin IF DBVREP.DBRSAPPLY_PKG.is_dbreplicate_session=FALSE then :new.last_updated:=systimestamp; END IF; end; / |