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

I just picked out “Adjustable Race” as our victim, but you could have chosen any ProductID, as long as
you set the value to less than 50 percent of its previous value. If you do, you’ll get the expected error:
Msg 50000, Level 16, State 1, Procedure ProductIsRationed, Line 16
Cannot reduce stock by more than 50% at once.
Msg 3609, Level 16, State 1, Line 1
The transaction ended in the trigger. The batch has been aborted.
Note that we could have also implemented this in the SalesOrderDetail table by referencing the actual
order quantity against the current Quantity amount, but we would have run into several problems:
❑ Updates that change: Is the process that’s creating the SalesOrderDetail record updating
ProductInventory before or after the SalesOrderDetail record? That makes a difference in
how we make use of the Quantity value in the ProductInventory table to calculate the effect
of the transaction.
❑ The inventory external to the SalesOrderDetails table updates would not be affected: They
could still reduce the inventory by more than half (this may actually be a good thing in many
circumstances, but it’s something that has to be thought about).
Using Triggers for Custom Error Messages
We’ve already touched on this in some of our other examples, but remember that triggers can be handy
for when you want control over the error message or number that gets passed out to your user or client
application.
With a CHECK constraint for example, you’re just going to get the standard 547 error along with its rather
nondescript explanation. As often as not, this is less than helpful in terms of the user really figuring out
what went wrong — indeed, your client application often doesn’t have enough information to make an
intelligent and helpful response on behalf of the user.
In short, sometimes you create triggers when there is already something that would give you the data
integrity that you want, but won’t give you enough information to handle it.
It’s worth noting that the need for custom error messages in SQL Server should be relatively rare, although
passing custom error codes is often useful. Why not pass the custom error message? Well, one would
think that you probably have an application layer on top of it, and it is likely going to want to put more
context on the error anyway, so the SQL-Server-specific text may not be all that useful. Using a special
error code may, however, be very useful to your application in terms of determining what exactly happened
and applying the correct client-side error handling code.
Other Common Uses for T riggers
In addition to the straight data integrity uses, triggers have a number of other uses. Indeed, the possibilities
are fairly limitless, but here are a few common examples:
❑ Updating summary information
Chapter 15: Triggers
461