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

Next we have a DECLARE statement to declares a variable. We've seen DECLARE statements used in a few
scripts used earlier in the book, but let's visit them a bit more formally.
Declaring Variables
The DECLARE statement has a pretty simple syntax:
DECLARE @ [= ][,
@ [= ][,
@ [= ]]]
You can declare just one variable at a time, or several. It’s common to see people reuse the DECLARE
statement with each variable they declare, rather than use the comma-separated method. It’s up to you,
but no matter which method you choose, you must initialize the variable (using the "=" syntax) or the
value of your variable will be NULL until you explicitly set it to some other value.
In this case, we’ve declared a local variable called @ident as an integer. I've chosen not to initialize it as
the whole purpose of this variable is to accept a value from another source. Technically, we could have
gotten away without declaring this variable — instead, we could have chosen to just use @@IDENTITY
directly. @@IDENTITY is a system function. It is always available, and supplies the last identity value that
was assigned in the current connection. As with most system functions, you should make a habit of
explicitly moving the value in @@IDENTITY to a local variable. That way, you’re sure that it won’t get
changed accidentally. There was no danger of that in this case, but, as always, be consistent.
Setting the Value in Your Variables
Chapter 11: Writing Scripts and Batches
I like to move a value I’m taking from a system function into my own variable. That
way I can safely use the value and know that it’s being changed only when I change
it. With the system function itself, you sometimes can’t be certain when it’s going to
change because most system functions are not set by you, but by the system. That
creates a situation where it would be very easy to have the system change a value at
a time you weren’t expecting it, and wind up with the most dreaded of all computer
terms: unpredictable results.
Well, we now know how to declare our variables, but the question that follows is, “How do we change
their values?” There are two ways to set the value in a variable. You can use a SELECT statement or a SET
statement. Functionally, they work almost the same, except that a SELECT statement has the power to
have the source value come from a column within the SELECT statement.
So why have two ways of doing this? Actually, I still don’t know. After publishing four books that ask
this very question, I figured someone would e-mail me and give me a good answer — they didn’t. Suffice
to say that SET is now part of the ANSI/ISO standard, and that’s why it’s been put in there. However, I
can’t find anything wrong with the same functionality in SELECT — even ANSI/ISO seems to think that
it’s OK. I’m sure there’s a purpose in the redundancy, but what it is I can’t tell you. That said, there are
some differences in the way they are used in practice.
327