Creating a Trigger Function

Creating a Trigger Function

To define a function as being a trigger function, use the TRIGGER parameter on the FUNCTION command.

If the function is to act as a data dictionary level trigger, enter *FIELD into the first part of the parameter, and the associated data dictionary field name into the second part of the parameter.

If the function is to act as a database level trigger, enter *FILE into the first part of the parameter, and the associated database file name into the second part of the parameter. The file specified must be a physical file.

As an aid to defining new trigger functions LANSA is shipped with the following Application Templates that can be used to form the base of a trigger function:

When a function is defined as a trigger function you must follow these guidelines:

• The parameter RCV_LIST(#TRIG_LIST) must be used.

• The parameter RCV_DS must not be used.

• Option *DIRECT must also be used.

• Options xxx_SYSTEM_VARIABLE or xxx_FIELD_VALIDATE must not be used.

• The list #TRIG_LIST must be defined by a DEF_LIST command as DEF_LIST NAME(#TRIG_LIST) TYPE(*WORKING) ENTRYS(2) and must not include any fields in the FIELDS parameter. The required fields will be automatically added.

• No DISPLAY, REQUEST or POP_UP commands may be used. This is a deliberately imposed design/usage constraint that may be removed in later versions.

• No CALL can exist to another process/function. This is a deliberately imposed design/usage constraint that may be removed in later versions.

• Trigger functions cannot be defined within an action bar process. This is not to say that they cannot be referenced from within an action bar, it just means that a trigger function cannot be defined as part of a process that is of action bar type.

• The associated process must not have any parameters.

• The exchange list may not be used. This is a deliberately imposed design/usage constraint imposed to enforce insulated and modular design and use of trigger functions.

When a function is defined as a trigger function you should follow these guidelines in most situations:

• Understand how triggers are defined and how they should be used by reading the Field Rules/triggers sections and Trigger Functions section.

• Use options *NOMESSAGES and *MLOPTIMIZE.

• Options *HEAVYUSAGE and *DBOPTIMIZE may also be considered.

• Do not directly or indirectly access the database file that the trigger is, or will be, linked to.

• Where triggers are heavily and constantly invoked avoid resource intensive operations. Such operations will slow down access to the associated file. Whenever reasonable make the trigger "submit" another transaction thus not delaying the source of the event significantly.

• Recursive implementations may be defined, but will fail to execute correctly. For instance a field trigger function invoked during an insert to file A could attempt to insert data into file B, possibly causing itself to be invoked in a recursive situation, and thus to fail.