Table of Contents
- Microsoft SQL Server Defined
- Microsoft SQL Server Features
- Microsoft SQL Server Administration
Microsoft SQL Server Programming
- An Outline for Development
- Database Services
- Database Objects: Databases
- Database Objects: Tables
- Database Objects: Table Relationships
- Database Objects: Keys
- Database Objects: Constraints
- Database Objects: Data Types
- Database Objects: Views
- Database Objects: Stored Procedures
- Database Objects: Indexes
- Database Objects: User Defined Functions
- Database Objects: Triggers
- Database Design: Requirements, Entities, and Attributes
- Business Process Model Notation (BPMN) and the Data Professional
- Business Questions for Database Design, Part One
- Business Questions for Database Design, Part Two
- Database Design: Finalizing Requirements and Defining Relationships
- Database Design: Creating an Entity Relationship Diagram
- Database Design: The Logical ERD
- Database Design: Adjusting The Model
- Database Design: Normalizing the Model
- Creating The Physical Model
- Database Design: Changing Attributes to Columns
- Database Design: Creating The Physical Database
- Database Design Example: Curriculum Vitae
- The SQL Server Sample Databases
- The SQL Server Sample Databases: pubs
- The SQL Server Sample Databases: NorthWind
- The SQL Server Sample Databases: AdventureWorks
- The SQL Server Sample Databases: Adventureworks Derivatives
- UniversalDB: The Demo and Testing Database, Part 1
- UniversalDB: The Demo and Testing Database, Part 2
- UniversalDB: The Demo and Testing Database, Part 3
- UniversalDB: The Demo and Testing Database, Part 4
- Getting Started with Transact-SQL
- Transact-SQL: Data Definition Language (DDL) Basics
- Transact-SQL: Limiting Results
- Transact-SQL: More Operators
- Transact-SQL: Ordering and Aggregating Data
- Transact-SQL: Subqueries
- Transact-SQL: Joins
- Transact-SQL: Complex Joins - Building a View with Multiple JOINs
- Transact-SQL: Inserts, Updates, and Deletes
- An Introduction to the CLR in SQL Server 2005
- Design Elements Part 1: Programming Flow Overview, Code Format and Commenting your Code
- Design Elements Part 2: Controlling SQL's Scope
- Design Elements Part 3: Error Handling
- Design Elements Part 4: Variables
- Design Elements Part 5: Where Does The Code Live?
- Design Elements Part 6: Math Operators and Functions
- Design Elements Part 7: Statistical Functions
- Design Elements Part 8: Summarization Statistical Algorithms
- Design Elements Part 9:Representing Data with Statistical Algorithms
- Design Elements Part 10: Interpreting the Data—Regression
- Design Elements Part 11: String Manipulation
- Design Elements Part 12: Loops
- Design Elements Part 13: Recursion
- Design Elements Part 14: Arrays
- Design Elements Part 15: Event-Driven Programming Vs. Scheduled Processes
- Design Elements Part 16: Event-Driven Programming
- Design Elements Part 17: Program Flow
- Forming Queries Part 1: Design
- Forming Queries Part 2: Query Basics
- Forming Queries Part 3: Query Optimization
- Forming Queries Part 4: SET Options
- Forming Queries Part 5: Table Optimization Hints
- Using SQL Server Templates
- Transact-SQL Unit Testing
- Index Tuning Wizard
- Unicode and SQL Server
- SQL Server Development Tools
- The SQL Server Transact-SQL Debugger
- The Transact-SQL Debugger, Part 2
- Basic Troubleshooting for Transact-SQL Code
- An Introduction to Spatial Data in SQL Server 2008
- Performance Tuning
- Practical Applications
- Professional Development
- Application Architecture Assessments
- Business Intelligence
- Tips and Troubleshooting
- Additional Resources
Database Objects: Triggers
Last updated Mar 28, 2003.
In an upcoming series of articles, I'll explain how to correctly plan a database schema, and discuss how to implement a physical design with these objects. Finally, I'll explain how to write simple programs using that database. Before we get to all that, we need to cover one more database object: the trigger.
Put simply, a trigger is code that is run when various operations are performed on a table, such as inserts, updates, or deletes. As you'll see, they are very powerful.
It probably isn't too much of a mental leap to think about the fact that each time a user inserts, updates, or deletes data you can run some code. I'll show you the format for creating a trigger in a moment. The part that's important to understand first is how SQL Server does that.
The real magic lies in the fact that the trigger makes use of virtual tables. These tables hold the items that are about to be inserted or deleted. The trigger gives you access to the data in the virtual tables, and you can use that fact to manipulate all kinds of logic.
First, I'll show you the main three types of triggers, and then a very special trigger which can be placed on a table or a view. Along the way, you'll learn some potential ways a trigger can be used.
There are three types of conditions that will initiate a trigger, so there are three main types of triggers you can create: Insert, Update, and Delete. You can have multiples of each of those (or all of them) assigned on a single table.
Be careful with triggers, since they are fired for each operation. Every insert, update, or delete causes the code to run, which creates overhead. To be sure, there are times when a trigger is the only way to go, but be warned that they do have a performance impact.
Let's take a closer look at each type of trigger and how you can use them in your database.
Insert Triggers are fired whenever an insert operation is performed on a table. You'll often see these used to enforce referential integrity in situations where another type of constraint isn't advisable. You'll also see them used to populate another table during an insert.
Let's take a simple example using the pubs database. We'll put on an insert trigger that concatenates the first and last names and then inserts them into another table. First, of course, we'll need a table to catch the results:
CREATE TABLE [dbo].[TriggerTest] ( [au_id] [int] NULL, [au_name] [varchar] (50) ) GO
Notice that I've made a field called au_id to serve as the tracking field. Often, this kind of field will also serve as the foreign key we discussed a few articles back. I'll use that field when I put some other triggers on the authors table, so I can demonstrate how all the triggers work together.
Okay, we've got our secondary table ready; let's take a look at the trigger syntax for an insert on the authors table. I'm going to change format a bit from my previous articles and use in-line comments (with two dashes) to explain what's going on, right in the code:
-- Start of command CREATE TRIGGER tr_InsertConcatName -- The table name I want to affect ON authors -- The type of trigger I want FOR INSERT AS -- I'll set up two variables to hold the id's -- and names I want to use DECLARE @AuthorID VARCHAR(11) DECLARE @ConcatName VARCHAR(50) -- Now I'll make use of the inserted virtual table I mentioned, -- setting the values of the variables to the data the user -- sends. SELECT @AuthorID = (SELECT au_id FROM Inserted) SELECT @ConcatName = (SELECT au_lName + ', ' + au_fName FROM Inserted) -- And now I'll use those variables to insert data into -- the TriggerTest Table I made earlier INSERT TriggerTest values (@AuthorID, @ConcatName)
And there you have it. Notice the use of the virtual table. It moves one row at a time, so I can select the fields out of it into my variables, which I then turn around and insert into my TriggerTest. Now, each time data is inserted into the authors table, my TriggerTest table gets a new row:
INSERT authors (au_id, au_lname, au_fname, contract) VALUES ('123-45-6789', 'Woody', 'Buck', 1)
And now I'll select the data from that TriggerTest table to see if all this worked:
SELECT * FROM TriggerTest GO ------------------ 123-45-6789 Woody, Buck ----------
But what if someone updates the values in the authors table? Won't the information in the TriggerTest table be inaccurate? Yes it will, so we need to create the next type of trigger we have at our disposal, the Update Trigger. Once again, let's take a look at an example:
-- I start the trigger creation CREATE TRIGGER tr_UpdateConcatName -- Here's the operation type FOR UPDATE AS -- I'll set up the variables, -- This one holds the id DECLARE @AuthorID VARCHAR(11) -- and this one holds the name DECLARE @NewConcatName VARCHAR(50) -- Now I'll make use of the second virtual table, setting -- the variables to values from that table. SELECT @AuthorID = (SELECT au_id FROM Inserted) SELECT @NewConcatName = (SELECT au_lName + ', ' + au_fName FROM Inserted) -- And now I'll use those variables to update the data in -- the TriggerTest table UPDATE TriggerTest SET au_name = @NewConcatName WHERE au_id = @AuthorID
Did you notice that I mentioned that I used the second virtual table? In an update operation, what really happens is a delete operation and then an insert operation. That means there will be a virtual table holding the delete operations (called deleted) and one holding the insert operations (called inserted). I'll use the inserted table to create the new values to keep my other table in sync, since it contains the data I want. It's important to keep this in mind, since you may need to use the older set of values in your programming logic for the comparisons.
Let's try this out:
UPDATE authors SET au_fname = 'Greg' WHERE au_id = '123-45-6789' GO SELECT * from TriggerTest ----------- Woody, Greg -----------
The delete trigger is often used to enforce cascading deletes. You can perform the same thing by setting up a cascading delete operation on the table, but sometimes you want to reserve that logic for a trigger. I'll show you when each type is appropriate in a later article.
For now, I'll set up a delete trigger to remove records from my TriggerTest table when they are removed from the authors table. Once again, watch for the comments:
-- I start the create command CREATE TRIGGER tr_DeleteConcatName -- and here is the table name ON authors -- the operation type goes here FOR DELETE AS -- I just need one variable this time DECLARE @AuthorID VARCHAR(11) -- Now I'll make use of the deleted virtual table SELECT @AuthorID = (SELECT au_id FROM Deleted) -- And now I'll use that value to delete the data in -- the TriggerTest Table DELETE FROM TriggerTest WHERE au_id = @AuthorID
Running this SQL Statement:
DELETE FROM authors WHERE au_lname = 'Woody'
Erases the entry from the TriggerTest table.
The final type of trigger I'll explain briefly is the Instead Of Trigger. The Instead Of trigger means that the trigger code runs instead of the SQL statement you send. So when you send:
DELETE FROM authors WHERE au_lname = 'Woody'
What really runs is the code in the Instead Of trigger. Nothing is deleted, whether it matches 'Woody' or not.
Another interesting fact about Instead Of triggers is that you can place them on a view. This is quite useful, because (as you may recall from our study of views) only one "base" table can be updated through a view. With an Instead Of trigger you can update as many tables as you like. As a matter of fact, I know of some developers who create a view that doesn't do anything at all; it's only a "hanger" for the Instead Of trigger!
I won't cover the syntax of the Instead Of trigger in this article, but I've referenced some sites that do. Rest assured that we will use them in our future programming lessons.
Now, go ahead, get trigger-happy!
Online Resources Database Objects, Triggers
Use SQL Server Triggers to Track Unauthorized Database Changes.
Using Triggers in MS SQL Server by David Rusik
Using Triggers in MS SQL Server from devbuilder.
Read more about triggers from sitepoint.
InformIT Articles and Sample Chapters Database Objects, Triggers
Triggers Tips for SQL Server 2000 at InformIT.com