Synchronizing Databases
Page 9 of 11

Triggers and the Refresh Operation

In a Cloudsync application, you can handle a trigger in one of the following ways:

  1. The trigger is not published.

    The default.

  2. The trigger is published to the target, but changes made by the trigger are not sent to the source at refresh time.

    The usual situation when you publish a trigger.

  3. The trigger is published to the target, and some or all changes made by the trigger are sent to the source at refresh time.

    Usually unnecessary, and strongly discouraged.

By default, triggers are not published to the target. If you want the target to better imitate source behavior, you can publish triggers. Another advantage of publishing a trigger is that if a target trigger causes the transaction to fail, the transaction is never sent to the source, which may improve source performance. See Publishing Triggers for more information on publishing triggers.

Even if you publish a trigger, target data changes caused by the trigger on the current connection are not sent to the source at refresh time. (The exception is the inadvisable scenario in which the data changes are in a different connection from the refresh operation.) The synchronized system relies on the source trigger to change data appropriately. Changes caused by the source trigger are then sent back to the target at the end of the refresh operation. Note that this implies that if a trigger acts differently on the source than on the target, only the source trigger actions persist after the refresh operation completes. Additionally, not sending trigger-initiated data on refresh helps reduce the amount data that must be sent to the source.

While typically, target trigger actions are not sent to the source at refresh time, if the trigger performs work on a different connection than the default at the time the trigger fired, that work is sent to the source at the next refresh.

NOTE: Unless it is absolutely necessary, do not force your application to send target trigger actions to the source. It is best to preserve the atomicity of triggers and work units by not allowing them to open separate connections. Among other potential problems, multiple connections to the same database may cause a deadlock.