Products Support Documentation Download
Use of Triggers by Non-SQL RDM Core API Applications

Trigger execution is performed in the SQL subsystem but the firing of a row-level trigger (i.e., invoking the trigger execution) must be handled by the core runtime system so that Core API applications do not ignore any trigger definitions on the database. However, we do not want to create a dependency in which the SQL subsystem must be linked in with all Core API applications when they are not using triggers–which would be created by incorporating direct calls into SQL in the RDM runtime to execute a trigger. To avoid this, the following three new Core API functions are provided and need to be called by Core API applications when using a database that contains triggers.

rdm_dbTriggersOn()

This function must be called after the database has been opened but before any calls to Core API functions that modify the database are made. Should triggers be defined on the database and this function (or rdm_dbTriggersOff()) has not been called, then the runtime system will return errors on any calls that modify the database.

A successful return from this function will enable the use of the triggers defined on the database.

This function will reside in the SQL subsystem, which will call a runtime system function that will register a trigger execution callback function into the SQL system that will be called by the RDM runtime system to execute the triggers.

rdm_dbTriggersOff()

This function will disable the use of triggers. It will reside in the Core runtime system. It must be called after the database has been opened and will disable the use of triggers and allow database modification functions to be called.

rdm_dbTriggersStatus()

This function sets *pStat to indicate the triggers status for the database specified by db as follows:

0 => rdm_dbTriggersOn not (yet) called,
1 => rdm_dbTriggersOn has been called,

-1 => rdm_dbTriggersOff has been called.