Creating Triggers

as tables, views, and procedures. For example, a table and a trigger can have the same name (however, to avoid confusion, this is not recommended).

When Is the Trigger Fired?

A trigger is fired based on a triggering statement, which specifies:

■The SQL statement or the system event, database event, or DDL event that fires the trigger body. The options include DELETE, INSERT, and UPDATE. One, two, or all three of these options can be included in the triggering statement specification.

■The table, view, DATABASE, or SCHEMA associated with the trigger.

Note: Exactly one table or view can be specified in the triggering statement. If the INSTEAD OF option is used, then the triggering statement may only specify a view; conversely, if a view is specified in the triggering statement, then only the INSTEAD OF option may be used.

For example, the PRINT_SALARY_CHANGES trigger fires after any DELETE, INSERT, or UPDATE on the Emp_tab table. Any of the following statements trigger the PRINT_SALARY_CHANGES trigger given in the previous example:

DELETE FROM Emp_tab;

INSERT INTO Emp_tab VALUES ( ... );

INSERT INTO Emp_tab SELECT ... FROM ... ;

UPDATE Emp_tab SET ... ;

Do Import and SQL*Loader Fire Triggers?

INSERT triggers fire during SQL*Loader conventional loads. (For direct loads, triggers are disabled before the load.)

The IGNORE parameter of the IMP command determines whether triggers fire during import operations:

■If IGNORE=N (default) and the table already exists, then import does not change the table and no existing triggers fire.

■If the table does not exist, then import creates and loads it before any triggers are defined, so again no triggers fire.

Using Triggers 9-5