Triggers & Packages

An SQL trigger is a mechanism that automatically executes a specified PL/SQL block (referred to as the
triggered action) when a triggering event occurs on the table. The triggering event may be one of insert,
delete, or update. The trigger is associated with a database table and is fired when the triggering event
takes place on the table. The syntax for creating a trigger is as follows:

CREATE [OR REPLACE ] TRIGGER trigger_name

{BEFORE | AFTER | INSTEAD OF }

{INSERT [OR] | UPDATE [OR] | DELETE}

[OF col_name]

ON table_name

[REFERENCING OLD AS o NEW AS n]

[FOR EACH ROW]

WHEN (condition)

DECLARE

Declaration-statements

BEGIN

Executable-statements

EXCEPTION

Exception-handling-statements

END;

Where,

 CREATE [OR REPLACE] TRIGGER trigger_name: Creates or replaces an existing trigger with the
trigger_name.

 {BEFORE | AFTER | INSTEAD OF} : This specifies when the trigger would be executed. The INSTEAD OF
clause is used for creating trigger on a view.

 {INSERT [OR] | UPDATE [OR] | DELETE}: This specifies the DML operation.

 [OF col_name]: This specifies the column name that would be updated.

 [ON table_name]: This specifies the name of the table associated with the trigger.

 [REFERENCING OLD AS o NEW AS n]: This allows you to refer new and old values for various DML
statements, like INSERT, UPDATE, and DELETE.

 [FOR EACH ROW]: This specifies a row level trigger, i.e., the trigger would be executed for each row being
affected. Otherwise the trigger will execute just once when the SQL statement is executed, which is called
a table level trigger.

 WHEN (condition): This provides a condition for rows for which the trigger would fire. This clause is valid
only for row level triggers.

1
 Like a stored procedure, a trigger is a named PL/SQL unit that is stored in the database and can
be invoked repeatedly. Unlike a stored procedure, you can enable and disable a trigger, but you
cannot explicitly invoke it. While a trigger is enabled, the database automatically invokes it—
that is, the trigger fires—whenever its triggering event occurs. While a trigger is disabled, it
does not fire.

 Syntax for creating triggers:

Example:

Let’s create a simple table (T_Cust), with the following schema:

and insert a few tuples, as shown below, a table of 5 tuples:

2
The following program creates a row level trigger for the T_Cust table that would fire for INSERT or
UPDATE or DELETE operations performed on the T_Cust table. This trigger will display the salary
difference between the old values and new values. Let’s create the trigger first, as shown below:

3
Here following two points are important and should be noted carefully:

 OLD and NEW references are not available for table level triggers, rather you can use them for
record level triggers.

 If you want to query the table in the same trigger, then you should use the AFTER keyword,
because triggers can query the table or change it again only after the initial changes are applied
and the table is back in a consistent state.

 Above trigger has been written in such a way that it will fire before any DELETE or INSERT or
UPDATE operation on the table, but you can write your trigger on a single or multiple
operations, for example BEFORE DELETE, which will fire whenever a record will be deleted using
DELETE operation on the table.

Triggering a Trigger
Let us perform some DML operations on the T_Cust table. Here is one INSERT statement, which will
create a new record in the table. When a record is created in T_Cust table, above create trigger
display_salary_changes will be fired and it will display the following result:

Because this is a new record (id = 7), the old salary is not available and above result is coming as null.
Now, let us perform one more DML operation on the T_Cust table. Here is one UPDATE statement,
which will update an existing record in the table:

When a record is updated in T_Cust table, above created trigger display_salary_changes will be fired and it will
display the above result. This time, id of 2 exists, therefore you will see the old, new, salaries, and the salary
difference.

4
 Packages

PL/SQL packages are schema objects that groups logically related PL/SQL types, variables and
subprograms.

A package will have two mandatory parts:

 Package specification

 Package body or definition

Package Specification

The specification is the interface to the package. It just DECLARES the types, variables, constants,
exceptions, cursors, and subprograms that can be referenced from outside the package. In other words,
it contains all information about the content of the package, but excludes the code for the subprograms.

All objects placed in the specification are called public objects. Any subprogram not in the package
specification but coded in the package body is called a private object.

The following code snippet shows a package specification having a single procedure. You can have many
global variables defined and multiple procedures or functions inside a package.

The following creates a package with the name cust_sal1:

Package Body

The package body has the codes for various methods declared in the package specification and other
private declarations, which are hidden from code outside the package. The CREATE PACKAGE BODY
Statement is used for creating the package body. The following code snippet shows the package body
declaration for the cust_sal package created above. Since we already have T_Cust table created in our
database as mentioned in the previous (triggers section), we can try a simple program to test it.

Here it is:

Enter value for cc_id: 1

Salary: 7000

5
ANOTHER EXAMPLE:

The following program provides a more complete package. We will use the CUSTOMERS table stored in our
database with the following records:

THE PACKAGE SPECIFICATION:

6
CREATING THE PACKAGE BODY:

Before using the package, keep in mind that the current contents of the T_Cust table are the following 6
tuples:

7
USING THE PACKAGE

The following program uses the methods declared and defined in the package c_package.

Here is the final T-Cust table content:

8
Exercise:

In the Mail Order database, let us write a trigger on the MO_Odetails table. This trigger checks to see if
the quantity ordered is more than the quantity on hand. If it is, an error message is generated, and the
row is not inserted. Otherwise, the trigger updates the quantity on hand for the part and checks to see if
it has fallen below the reorder level. If it has, it sends a row to restock table indicating that the part
needs to be reordered.

Insert into MO_odetails values (2000, 10900, 10);

Insert into MO_odetails values (2000, 10506, 1500);

The first insert should be successful as the qoh (100) is more the order size. Whereas the second insert
will fir the trigger, as the qoh(200) is not sufficient to cover order size of 1500.

Use the trigger (insert_odetails shown in your text and the anonymous PL/SQL block (Pages 115-116 of
your text) to verify this conclusion.