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

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

cdn.s3techtraining.com
from cdn.s3techtraining.com More from this publisher
17.06.2013 Views

Chapter 15: Triggers Trigger Firing Order 464 In long ago releases of SQL Server (7.0 and prior), we had no control over firing order. Indeed, you may recall me discussing how there was only one of any particular kind of trigger (INSERT, UPDATE, DELETE) prior to 7.0, so firing order was something of a moot point. Later releases of SQL Server provide a limited amount of control over which triggers go in what order. For any given table (not views, since firing order can be specified only for AFTER triggers and views accept only INSTEAD OF triggers), you can elect to have one (and only one) trigger fired first. Likewise, you may elect to have one (and only one) trigger fired last. All other triggers are considered to have no preference on firing order — that is, there is no guarantee what order triggers with a firing order of NONE will fire in, other than that they will fire after the FIRST trigger (if there is one) is complete and before the LAST trigger (again, if there is one) begins (see Figure 15-3). Figure 15-3 Original statement completes FIRST trigger fires and completes NONE trigger NONE trigger NONE trigger LAST trigger Any of these could fire at any time after the FIRST completes (exact firing order may vary), but they will complete before the LAST is allowed to fire. The creation of a trigger that is to be FIRST or LAST works just the same as any other trigger. You state the firing order preference after the trigger has already been created using a special system stored procedure, sp_settriggerorder.

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

Chapter 15: Triggers<br />

Trigger Firing Order<br />

464<br />

In long ago releases of <strong>SQL</strong> <strong>Server</strong> (7.0 and prior), we had no control over firing order. Indeed, you may<br />

recall me discussing how there was only one of any particular kind of trigger (INSERT, UPDATE, DELETE)<br />

prior to 7.0, so firing order was something of a moot point. Later releases of <strong>SQL</strong> <strong>Server</strong> provide a limited<br />

amount of control over which triggers go in what order. For any given table (not views, since firing order<br />

can be specified only for AFTER triggers and views accept only INSTEAD OF triggers), you can elect to<br />

have one (and only one) trigger fired first. Likewise, you may elect to have one (and only one) trigger<br />

fired last. All other triggers are considered to have no preference on firing order — that is, there is no<br />

guarantee what order triggers with a firing order of NONE will fire in, other than that they will fire after<br />

the FIRST trigger (if there is one) is complete and before the LAST trigger (again, if there is one) begins<br />

(see Figure 15-3).<br />

Figure 15-3<br />

Original<br />

statement<br />

completes<br />

FIRST trigger<br />

fires and<br />

completes<br />

NONE trigger NONE trigger<br />

NONE trigger<br />

LAST trigger<br />

Any of these could<br />

fire at any time after<br />

the FIRST completes<br />

(exact firing<br />

order may vary), but<br />

they will complete<br />

before the LAST is<br />

allowed to fire.<br />

The creation of a trigger that is to be FIRST or LAST works just the same as any other trigger. You state<br />

the firing order preference after the trigger has already been created using a special system stored procedure,<br />

sp_settriggerorder.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!