2

3
4
5
Only the DBA can create DDL triggers on other users’ schemas (either by ON DATABASE or by ON schema-
name.SCHEMA)

To create a trigger in your own schema on a table in your own schema, you must have the CREATE TRIGGER
system privilege.

To create a trigger in any schema on a table in any schema, you must have the CREATE ANY TRIGGER
system privilege.

6
DDL triggers can specify only ON SCHEMA or ON DATABASE. We cannot say (for example) AFTER CREATE
ON TABLE.

Also, these are not like DML row triggers. We cannot use qualifiers such as :OLD and :NEW.

7
This trigger will not function properly in the Application Express development environment.

NOTE: This trigger will prevent dropping any schema objects, even the trigger itself. Dropping the trigger
involves two steps:

1. ALTER TRIGGER prevent_drop_trigg DISABLE;

8
Remember, you cannot use INSTEAD OF with Database Event triggers.

You can define triggers to respond to such system events as LOGON, SHUTDOWN, and even SERVERERROR.

Database Event triggers can be created ON DATABASE or ON SCHEMA, except that ON SCHEMA cannot be
used with SHUTDOWN and STARTUP events.

9
10
You can create these triggers to monitor how often you log on and off, or you may want to write a report
that monitors the length of time for which you are logged on.

The LOGOFF trigger will not fire if the user’s session disconnects abnomally.

11
12
Trigger syntax also supports a CALL to a procedure as the trigger body. It can also be used to call programs
written in C or JAVA.

13
14
15
16
The CHECK_SALARY trigger in the example attempts to guarantee that whenever a new employee is added
to the EMPLOYEES table or whenever an existing employee’s salary or job ID is changed, the employee’s
salary falls within the established salary range for the employee’s job.

When an employee record is updated, the CHECK_SALARY trigger is fired for each row that is updated. The
trigger code queries the same table that is being updated. Therefore, it is said that the EMPLOYEES table is
a mutating table.

A trigger (such as check_salary in the slide) which violates the mutating table restriction can still be
CREATEd, i.e. it will compile successfully. But an exception will be raised when the triggering DML
statement is executed, as shown in the next slide.

17
Possible solutions to this mutating table problem include the following:

Store the summary data (the minimum salaries and the maximum salaries) in another summary table,
which is kept up-to-date with other DML triggers.

Store the summary data in a PL/SQL package, and access the data from the package. This can be done in a
BEFORE statement trigger.

Implement the rules in the application code instead of in the database.

18
19
The trigger code shown in the slide prevents anyone (not only SCOTT) from updating salaries on Saturday
or Sunday. If you wanted this restriction to apply only to SCOTT, you could code:

CREATE OR REPLACE TRIGGER weekdays_emp

20
21
22
23
24
25
26
The departments.total_salary column is an example of derived data. Although it violates the data modeling
rules of normalization, sometimes this has to be done to improve performance.

27
The slide shows a procedure and a trigger which invokes the procedure three times. This avoids having to
code three separate UPDATE DEPARTMENTS ... statements within the trigger body.

28
• CALL statement – enables you to call a stored procedure, rather than code the PL/SQL body in the
trigger itself.
• Database Event triggers – are fired by non-SQL events in the database.
• DDL Triggers – are fired by DDL statements: CREATE, ALTER or DROP.
• Mutating table – A table that is currently being modified by an UPDATE, DELETE, or INSERT statement,
or a table that might need to be updated by the effects of a declarative DELETE CASCADE referential
integrity action.

29
30