1
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.
2
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:
3
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:
4
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.
5 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
6 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:
7 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:
8 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:
9 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.
