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

The syntax of sp_settriggerorder looks like this:
sp_settriggerorder[@triggername =] ‘’,
[@order =] ‘{FIRST|LAST|NONE}’,
[@stmttype =] ‘{INSERT|UPDATE|DELETE}’
[, [@namespace =] {‘DATABASE’ | ‘SERVER’ | NULL} ]
There can be only one trigger that is considered to be FIRST for any particular action (INSERT, UPDATE,
or DELETE). Likewise, there can be only one LAST trigger for any particular action. Any number of triggers
can be considered to be NONE — that is, the number of triggers that don’t have a particular firing
order is unlimited.
So, the question should be, why do I care what order they fire in? Well, often you won’t care at all. At
other times, it can be important logic-wise or just a good performance idea. Let’s consider what I mean
in a bit more detail.
Controlling Firing Order for Logic Reasons
Why would you need to have one trigger fire before another? The most common reason would be that
the first trigger lays some sort of foundation for, or otherwise validates, what will come afterwards.
Separate triggers also allow one part of the code to be disabled (remember that NO CHECK thing we did
a few sections ago?) while other parts of the code continue to function. The downside is that, if you go
ahead and separate your code into separate triggers, you lose the logical stepping order that the code
had when it was in one trigger.
By having at least a simple level of control over firing order, we have something of the best of both
worlds — we can logically separate our triggers, but still maintain the necessary order of precedence on
what piece of code runs first or last.
Controlling Firing Order for Performance Reasons
On the performance front, a FIRST trigger is the only one that really has any big thing going for it. If you
have multiple triggers, but only one of them is likely to generate a rollback (for example, it may be enforcing
a complex data integrity rule that a constraint can’t handle), you would want to consider making such a
trigger a FIRST trigger. This ensures that your most likely cause of a rollback is already considered before
you invest any more activity in your transaction. The more you do before the rollback is detected, the
more that will have to be rolled back. Get the highest probability of a rollback happening determined
before performing additional activity.
INSTEAD OF T riggers
Chapter 15: Triggers
INSTEAD OF triggers were added in SQL Server 2000 and remain one of the more complex features of
SQL Server. While it is well outside the scope of a “beginning” concept, I’m still a big believer in even
the beginner learning about what things are available, and so we’ll touch on what these are about here.
Essentially, an INSTEAD OF trigger is a block of code we can use as an interceptor for anything that anyone
tries to do to our table or view. We can either go ahead and do whatever the user requests or, if we
choose, we can go so far as doing something that is entirely different.
465