A trigger is a program unit that is executed (fired) due to an event. You can use triggers to add or modify form functionality in a procedural way. These events include the following:
Data entry and validation
Logical or physical navigation
Internal events in the form
Errors and messages
There are three main components to consider when you design a trigger in Forms Builder
The trigger type determines which type of event fires it. There are more than 100 built-in triggers, each identified by a specific name. Triggers are mostly fired by events within a form module.
The code of the trigger defines the actions for the trigger to perform when it fires.
The scope of a trigger is determined by its position in the form object hierarchy. There are three possible levels
Form level: The trigger belongs to the form and can fire due to events across the entire form
Block level: The trigger belongs to a block and can fire only when this block is the current block
Item level: The trigger belongs to an individual item and can fire only when this item is the current item
Trigger Execution Hierarchy
When there is more than one trigger of the same type, you can alter the firing sequence of a trigger by setting the execution hierarchy (EH) trigger property. This diagram shows how setting EH affects the firing order of triggers:
1. Fires first
2. Fires second
3. Fires third
4. Fires independently
In the Object Navigator, select the Triggers node of the form, block, or item that will own the trigger. Alternatively, you can select an item in the Layout Editor if you are defining an item level trigger.
Use the PL/SQL Editor to define the trigger code.
Click the Compile icon in the PL/SQL Editor to compile the trigger. This displays immediate feedback in the form of compilation error messages, which you can correct. If the trigger compiles correctly, a message displays in the lower right corner of the editor.
Whenever form server receives signals for Query whether internally or externally, it fires certain triggers in specific sequence. Its understanding is really very useful if we need to customize the query process as necessary, and supplement the results returned by a query. The sequence of the various triggers which are fired under Query operation are:
PRE-QUERY: Used to construct WHERE clause
ON-QUERY: Used to construct SELECT statement and executes it
POST-QUERY: Used to populate non-database items
Query Triggers Detailed Process
The Validation Levels:
Forms performs a validation process at several levels to ensure that records and individual values follow appropriate rules. If validation fails, then control is passed back to the appropriate level, so that the operator can make corrections. Validation occurs at:
There are few methods which can be implemented to perform validations. Some of these are:
Using Object Properties
Using List of Values
There are few triggers that fire due to validation, which let you add your own customized actions. There are also some built-in subprograms that you can call from triggers that affect validation. These triggers are:
Navigation occurs when the user or a trigger causes the input focus to move to another object. In addition to the visible navigation that occurs, some logical navigation takes place. This logical navigation is also known as internal navigation.
Example: When you enter a form module, you see the input focus in the first enterable item of the first navigation block. You do not see the internal navigation events that must occur for the input focus to enter the first item. These internal navigation events are as follows:
Entry to form
Entry to block
Entry to record
Entry to item
Controlling Navigation using triggers
The navigation triggers can be subdivided into two general groups:
Pre- and Post- navigation triggers
The Pre- and Post- navigation triggers fire during navigation, just before entry to or just after exit from the object specified as part of the trigger name.
The When-New-<object>-Instance triggers fire immediately after navigation to the object specified as part of the trigger name.
While applying a user’s changes to the database, Forms Builder enables you to make triggers fire in order to alter or add to the default behavior.
When Forms is asked to save the changes made in a form by the user, a process takes place involving events in the current database transaction. This process includes:
Default Forms transaction processing: Applies the user’s changes to the base tables
Firing transactional triggers: Needed to perform additional or modified actions in the saving process defined by the designer When all of these actions are successfully completed, Forms commits the transaction, making the changes permanent.
Some of Forms Builder built-in subprograms provide the same type of run-time status information that built-in system variables do. Some of the Get object property Built – in are:
Some of the Set object property Built – in are: