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

5, and 7, then you need to add the binary value of each bit: 2 + 16 + 64. Then you need to compare the
sum of the binary values of your columns to the bitmask by using bitwise operators:
❑ | Represents bitwise OR
❑ & Represents bitwise AND
❑ ^ Represents bitwise Exclusive OR
As I read back over what I’ve just written, I realize that it is correct, but about as clear as mud, so let’s
look a little closer at what I mean with a couple of examples.
Imagine that we updated a table that contained five columns. If we updated the first, third, and fifth
columns, the bitmask used by COLUMNS_UPDATED would contain 10101000, from 1 + 4 + 16 = 21. We
could use:
❑ COLUMNS_UPDATED() > 0 to find out if any column was updated
❑ COLUMNS_UPDATED() ^ 21 = 0 to find out if all of the columns specified (in this case 1, 3, and
5) were updated and nothing else was
❑ COLUMNS_UPDATED() & 21 = 21 to find out if all of the columns specified were updated, but
the state of other columns doesn’t matter
❑ COLUMNS_UPDATED | 21 != 21 to find out if any column other than those we’re interested in
was updated
Understand that this is tough stuff — boolean math is not exactly the easiest of concepts to grasp for
most people, so check things carefully and TEST, TEST, TEST!
Keep It Short and Sweet
I feel like I’m stating the obvious here, but it’s for a good reason.
I can’t tell you how often I see bloated, stupid code in sprocs and triggers. I don’t know whether it’s that
people get in a hurry, or if they just think that the medium they are using is fast anyway, so it won’t matter.
Remember that a trigger is part of the same transaction as the statement in which it is called. This means
the statement is not complete until your trigger is complete. Think about it — if you write long-running
code in your trigger, this means that every piece of code that you create that causes that trigger to fire
will, in turn, be long running. This can really cause heartache when you are trying to figure out why
your code is taking so long to run. You write what appears to be a very efficient sproc, but it performs
terribly. You may spend weeks and yet never figure out that your sproc is fine — it just fires a trigger
that isn’t.
Don’t Forget Triggers When Choosing Indexes
Chapter 15: Triggers
Another common mistake. You look through all your sprocs and views figuring out what the best mix of
indexes is — and totally forget that you have significant code running in your triggers.
469