You should choose only one of these methods for each data group file entry. Which method you use depends on a variety of considerations:
-
The default replication type for data group file entry options is positional replication. With positional replication, each file is replicated based on the position of the record within the file. The value of the relative record number used in the journal entry is used to locate a database record being updated or deleted. When positional replication is used and triggers fire on the target system they can cause trigger-induced modifications to the files being replicated. These trigger-induced modifications can change the relative record number of the records in the file because the relative record numbers of the trigger-induced modifications are not likely to match the relative record numbers generated by the same triggers on the source system. Because of this, triggers should not be allowed to fire on the target system. You should prevent the triggers from firing on the target system and replicate the trigger-induced modifications from source to the target system.
-
When trigger-induced modifications are made by replicated files to files not replicated by MIMIX, you may want the triggers to fire on the target system. This will ensure that the files that are not replicated receive the same trigger-induced modifications on the target system as they do on the source system.
-
When triggers do not cause database record changes, you may choose to allow them to fire on the target system. However, if non-database changes occur and you are using object replication, the object replication will replicate trigger-induced object changes from the source system. In this case, the triggers should not be permitted to fire.
-
When triggers are allowed to fire on the target system, the files being updated by these triggers should be replicated using the same apply session as the parent files to avoid lock contention.
-
A slight performance advantage may be achieved by replicating the trigger-induced modifications instead of ignoring them and allowing the triggers to fire. This is because the database apply process checks each transaction before processing to see if filtering is required, and firing the trigger adds additional overhead to database processing.