What Is A Database Trigger
What Is A Database Trigger
What Is A Database Trigger
A database trigger is special stored procedure that is run when specific actions occur within a database.
Most triggers are defined to run when changes are made to a table’s data. Triggers can be defined to
run instead of or after DML (Data Manipulation Language) actions such as INSERT, UPDATE, and
DELETE.
Triggers help the database designer ensure certain actions, such as maintaining an audit file, are completed
regardless of which program or user makes changes to the data.
The programs are called triggers since an event, such as adding a record to a table, fires their execution.
Triggers and their implementations are specific to database vendors. In this article we’ll focus on
Microsoft SQL server; however, the concepts are the same or similar in Oracle and MySQL.
Note: All the examples for this lesson are based on Microsoft SQL Server Management Studio and the
AdventureWorks2012 database.
The triggers can occur AFTER or INSTEAD OF a DML action. Triggers are associated with the database
DML actions INSERT, UPDATE, and DELETE. Triggers are defined to run when these actions are
executed on a specific table.
AFTER triggers
Once the DML actions, such as an INSERT completes, the AFTER trigger executes. Here are some key
characteristics of AFTER triggers:
After triggers are run after a DML action, such as an INSERT statement and any ensuing referential
cascade actions and constraint checks have run.
You can’t cancel the database action using an AFTER trigger. This is because the action has already
completed.
One or more AFTER triggers per action can be defined on a table, but to keep things simple I recommend
only defining one.
You can’t define AFTER triggers on views.
INSTEAD OF triggers
INSTEAD OF triggers, as their name implies, run in place of the DML action which caused them to fire.
Items to consider when using INSTEAD OF triggers include:
An INSTEAD OF trigger overrides the triggering action. If an INSTEAD OF trigger is defined to execute
on an INSERT statement, then once the INSERT statement attempt to run, control is immediately passed to
the INSTEAD OF trigger.
At most, one INSTEAD OF trigger can be defined per action for a table. This makes sense, as if you had to
“INSTEAD OF” triggers for an insert, which one should run?
Triggers use two special database objects, INSERTED and DELETED, to access rows affected by the
database actions. Within the scope of a trigger the INSERTED and DELETE objects have the same
columns as the trigger’s table.
The INSERTED table contains all the new values; whereas, the DELETED table contains old values. Here
is how the tables are used:
INSERT – Use the INSERTED table to determine which rows were added to the table.
DELETE – Use the DELETED table to see which rows were removed from the table.
UPDATE – Use the INSERTED table to inspect the new or updated values and the DELETED table to see
the values prior to update.
Definition
A trigger is defined for a specific table and one or more events. In most database management systems you
can only define one trigger per table.
1. The CREATE Statement – It defines which table is associated with the trigger. In addition this statement is
used to specify when the trigger executes (e.g. after insert).
2. The actual program. In the example, this program runs whenever one or more rows are inserted into the
WorkOrder table.
3. Special database objects – Triggers use specially defined databases objects such as INSERTED, or
DELETED to access records affected by the database action.
4. In this example the trigger is using the INSERTED object to gain access to the newly created rows. The
INSERT statement is used to table those rows and add them to a history table.
Complex Auditing
You can use triggers to track changes made to tables. In our example above, changes made to the
WorkOrder table are recorded a TransactionHistory table.
Typically when creating audit trails, you’ll use AFTER triggers.
You may think this is redundant, as many changes are logged in the databases journals, but the logs are
meant for database recovery and aren’t easily accessible by user programs. The TransactionHistory table is
easily referenced and can be incorporated into end user reports.
Triggers can be used to inspect all data before a DML action is performed. You can use INSTEAD OF
triggers to “intercept” the pending DML operation, apply any business rules, and ultimately complete the
transaction.
Triggers can be used to calculate column values. For instance, for each customer you may wish to
maintain a TotalSales column on the customer record. Of course, for this to remain accurate, it would have
to be update every time a sales was made.
This could be done using an AFTER trigger on INSERT, UPDATE, and DELETE statements for the Sales
table.
AFTER INSERT trigger executes after a record is inserted into the database. Open a new
query window and write below statements
A stored procedure is a group of one or more database statements stored in the database’s data dictionary
and called from either a remote program, another stored procedure, or the command line. Stored procedure
are commonly called SPROCS, or SP’s. Stored procedure features and command syntax are specific to the
database engine. Traditionally Oracle uses PL/SQL as its language; whereas, SQL Server uses T/SQL.
Inputs
Store procedure can accept parameter values as inputs. Depending on how the parameters are defined,
modified values can be passed back to the calling program
Execution
Stored procedures can execute SQL statements, utilize conditional logic such as IF THEN or CASE
statements and lopping constructs to perform tasks.
A stored procedure is able to call another stored procedure.
Stored procedure can become very handy as they can manipulate results of SQL queries via cursors.
Cursors allow the procedure to access results row by row. In essence you can use cursors to loop through a
SQL statement’s result. This can slow down database performance, so be intelligent about your use of
cursors!
Outputs
Stored procedure can return single values such as a number or text value or a result set (set of rows). Also,
as mentioned, depending on how the inputs are defined, changed values to inputs can be propagated back to
the calling procedure.
Here is an example of a stored procedure that takes a parameter, executes a query and returns a result.
Specifically, the stored procedure accepts the BusinessEntityID as a parameter and uses this to match the
primary key of the HumanResources.Employee table to return the requested employee.
Stored procedures can be called from within SQL server. To call this stored procedure from the SQL
server command line or from another stored procedure you would use the following:
exec HumanResources.uspFindEmployee 3