st={ ON | OFF }; ...

SendTriggers={ ON | OFF }; ...

Cascaded deletes are also considered trigger actions.

The default is OFF.

If two subscriptions both contain one or more of the same tables, then both subscriptions must be synchronized using the same setting for the SendTriggers option.

In order for an operation in a trigger to be synchronized when the SendTrigger option is set to ON, the operation in the trigger must occur on a table in a publication that is being synchronized. It is not necessary for the base operation that caused the trigger to fire to be in the publication as well.

Dbmlsync coalesces operations that occur on a single row, but if the SendTrigger option is set to ON, then all the operations that fire in the trigger are also sent, even if the base operation that caused the trigger to fire is coalesced into another operation.

Built in referential integrity actions on foreign keys (ON DELETE CASCADE and ON UPDATE CASCADE) are considered trigger actions, and will not synchronize unless the SendTrigger option is set to ON. The one exception is the case where a referential integrity action takes place on a row that is already in the upload stream. In this case, the referential integrity action in the system generated trigger is coalesced with the state of the row that is already in the upload stream, as illustrated in the following example.

In this example, there is a foreign key between the Parent table and the Child table, with a referential integrity action of ON DELETE CASCADE.

INSERT INTO Parent (pid, pname) values ( 100, 'Amy' );
INSERT INTO Child (cid, pid, cname) values ( 2000, 100, 'Alex' );
COMMIT;
DELETE FROM Parent WHERE pid = 100;
COMMIT;

It is important to note that the RI action also deletes row 2000 from the Child table when you delete row 100 from the Parent table. If dbmlsync were run at this point, the INSERT and then DELETE on row 100 of the Parent table would result in the row not being synchronized. However, the insert into the Child table would be sent if the SendTrigger option is set to OFF. In this case, because dbmlsync has already added row 2000 of the Child table into the upload stream, the referential integrity action on the delete of row 100 on the Parent table, which deletes row 2000 of the Child table, is coalesced with the existing row in the upload stream, resulting in neither row being synchronized, and maintaining the consistency of the data at both sides.

The following dbmlsync command line illustrates how you can set this option when you start dbmlsync:

dbmlsync -e "st=on"

The following SQL statement illustrates how you can store this option in the database:

CREATE SYNCHRONIZATION SUBSCRIPTION
   TO sales_publication
   FOR ml_user1
   OPTION st='on';