Previous | Table of Contents | Next

Page 381

CHAPTER 15

Using Triggers and
Modifying Classes

You can use form file EMPCH15.FMB to practice any of the techniques in this chapter. Form file EMPCH15A.FMB is used in the Using Triggers to Change Form Canvases section, later in this book. This form is similar to the final form created in Chapter 14 (EMPCH14X.FMB). The difference is that the Post-query trigger that displays the employee images was removed.

Page 382

What Is a Trigger?

A trigger is an Oracle object that contains PL/SQL code and is fired or executed by a specific event. Triggers have a number of uses. They can be used to validate user entries, link and synchronize blocks of a form, redefine function keys, call other forms, define the action of a button, or perform a score of other functions. The techniques and functions that you learned in the PL/SQL chapters (Chapters 8 and 9) can be used in a trigger. This includes cursors, functions, procedures, packages, WHILE and FOR loops, and exception handling. In fact, it will be to your benefit to employ the full power of PL/SQL in your triggers.

When I first encountered triggers eight or nine years ago, the applications that I had been writing consisted of a single block of code in one file. The program began by reading the first line and continued executing statements until the last line of the file was read. I was able to follow the flow of the program following the logic from one line to the next. The programs had looping statements and goto keywords used to perform iterative procedures. These programs sometimes had stopping places where user input was requested. Essentially an application was a self-contained list of commands and all of the languages I knew such as BASIC, COBOL, or Focus worked in that manner.

Oracle Forms took the program listing out of my hands and replaced it with a series of event-driven triggers. The PL/SQL code is linked to a form object such as a block, item, or button and is executed by a specific action occurring. The developer no longer had the listing to follow. The developer needed to know what event occurred before the problem and what object was affected by the event. I found this an alien way to look at applications, but quickly found it a much easier way to develop and debug programs. I found it interesting that when I took my first look at Visual Basic, it looked a lot like Oracle Forms. Visual Basic ties the basic code to events and the events are linked to a form object. Microsoft had moved toward making its product look and operate like Oracle Forms.

Trigger Events

Triggers are named for the event that causes them to fire. In Chapter 14, a trigger was created to place a picture of an employee on the form when the employee's records were displayed. The name of the trigger was "Post-query" and was attached to block one, which meant that the associated PL/SQL code executed after a query was performed on block one.

There are many events that can fire a trigger. Some of these are pressing a button or function key, committing a record, or navigating to another record. Appendix B, "Triggers," contains a listing of the triggers and a description of the event that executes them.

Understanding the events that fire a trigger gives the developer a lot of control over the behavior of the form. For some triggers, it is easy to understand the event that executes the trigger. A When-button-pressed trigger fires when the associated button is clicked. For some of the triggers it is more difficult to determine which of the possible events to use. For instance, when an item is validated, six events occur. Triggers exist for each of the events. The item validation events and their order of occurrence are as follows:

Page 383

In looking at the preceding list there doesn't seem to be much difference between each of the events. Most of the time, the developer may choose any of the events and the trigger will produce the required results. Occasionally, the form requires the PL/SQL trigger to be executed at a specific time. For instance, the developer may want the trigger to format a value in an item. It might be more advantageous to format the item before the user tabs into the item rather than after the user tabs out. This gives the user the opportunity to change the formatting while the cursor is in the item rather than when it is in another item. This is why it is important to know that a variety of events can occur in sequence. The developer may choose or test a variety of events in the form to determine whether the desired results are attained.

Trigger Names

The name of a trigger contains information about when the trigger will be fired and the type of trigger. The beginning of the trigger name contains a keyword expressing when the trigger will be fired in relation to the specified event that follows the keyword. The keywords consist of When, On, Pre, and Post.

Triggers that begin with the word When provide extra processing to what is already being performed by Oracle as a result of the event. The On triggers take the place of the default processing for the event. The Pre triggers execute before the specified event occurs. The Post triggers fire after the specified event.

Trigger Failures

Triggers contain SQL statements. When a statement in the trigger fails, all processing stops and the form returns to the state before the event occurred. An error message appears on the message line at the bottom of the screen declaring a failure. If you do not want the processing to terminate, be sure to include exception handling in the PL/SQL. This will allow you to use more-descriptive error messages or save processing steps.

In some cases, the purpose of the trigger is to validate values. When the validation or edit process fails, the developer needs a way to terminate processing and return to the original state of the form. Triggers can be placed in the failure mode by executing the following command: raise form_trigger_failure. This command will terminate any trigger.

Previous | Table of Contents | Next