Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 15: Triggers
WITH ENCRYPTION
This works just as it does for views and sprocs. If you add this option, you can be certain that no one will
be able to view your code (not even you!). This is particularly useful if you are going to be building software
for commercial distribution, or if you are concerned about security and don’t want your users to be
able to see what data you’re modifying or accessing. Obviously, you should keep a copy of the code
required to create the trigger somewhere else, in case you want to re-create it sometime later.
As with views and sprocs, the thing to remember when using the WITH ENCRYPTION option is that you
must reapply it every time you use ALTER on your trigger. If you make use of an ALTER TRIGGER statement
and do not include the WITH ENCRYPTION option, then the trigger will no longer be encrypted.
The FOR|AFTER vs. the INSTEAD OF Clause
454
In addition to deciding what kind of queries will fire your trigger (INSERT, UPDATE, and/or DELETE),
you also have some choice as to when the trigger fires. While the FOR (alternatively, you can use the keyword
AFTER if you choose) trigger is the one that has been around a long time and that people generally
think of, you also have the ability to run what is called an INSTEAD OF trigger. Which of these two you
use will affect whether you enter your trigger before the data has been modified or after. In either case,
you will be in your trigger before any changes are truly committed to the database.
Confusing? Probably. Let’s try it a different way with a diagram that shows where each choice fires (see
Figure 15-1).
The thing to note here is that, regardless of which choice you make, SQL Server will put together two
working tables — one holding a copy of the records that were inserted (and, incidentally, called Inserted)
and one holding a copy of any records that were deleted (called Deleted). We’ll look into the uses of these
working tables a little later. For now realize that, with INSTEAD OF triggers, the creation of these working
tables will happen before any constraints are checked, with FOR triggers, these tables will be created after
constraints are checked. The key to INSTEAD OF triggers is that you can actually run your own code in
the place of whatever the user requested. This means we can clean up ambiguous INSERT problems in
views. It also means that we can take action to clean up constraint violations before the constraint is even
checked.
As positively glorious as this sounds, this is actually pretty complex stuff. It means that you need to
anticipate every possibility. In addition, it means that you are effectively adding a preprocess (a process
that runs before the main code) to every query that changes data in any way for this table (this is not a
good thing performance wise). Cool as they sound, INSTEAD OF triggers fall in the category of fairly
advanced stuff and are well outside the scope of this book.
Triggers using the FOR and AFTER declaration behave identically to each other. The big difference
between them and INSTEAD OF triggers is that they build their working tables after any constraints have
been checked.