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

Chapter 11: Writing Scripts and Batches
Beginning with SQL Server 2005, the sys.messages output got so lengthy that it’s hard to find what
you’re looking for by just scanning it. My solution is less than elegant but is rather effective — I just
artificially create the error I’m looking for and see what error number it gives me (simple solutions for
simple minds like mine!).
I simply execute the code I want to execute (in this case, the CREATE statement) and handle the error if
there is one — there really isn’t much more to it than that.
We will look at error handling in a far more thorough fashion our next chapter. In the meantime, you can
use TRY/CATCH to give basic error handling to your scripts.
Summary
364
Understanding scripts and batches is the cornerstone to an understanding of programming with SQL
Server. The concepts of scripts and batches lay the foundation for a variety of functions from scripting
complete database builds to programming stored procedures and triggers.
Local variables have scope for only one batch. Even if you have declared the variable within the same
overall script, you will still get an error message if you don’t re-declare it (and start over with assigning
values) before referencing it in a new batch.
There are many system functions available. We provided a listing of some of the most useful system functions,
but there are many more. Try checking out the Books Online or Appendix A at the back of this book
for some of the more obscure ones. System functions do not need to be declared, and are always available.
Some are scoped to the entire server, while others return values specific to the current connection.
You can use batches to create precedence between different parts of your scripts. The first batch starts at
the beginning of the script, and ends at the end of the script or the first GO statement — whichever comes
first. The next batch (if there is another) starts on the line after the first one ends and continues to the end
of the script or the next GO statement — again, whichever comes first. The process continues to the end
of the script. The first batch from the top of the script is executed first; the second is executed second,
and so on. All commands within each batch must pass validation in the query parser, or none of that
batch will be executed; however, any other batches will be parsed separately and will still be executed (if
they pass the parser).
We saw how we can create and execute SQL dynamically. This can afford us the opportunity to deal with
scenarios that aren’t always 100 percent predictable or situations where something we need to construct
our statement is actually itself a piece of data.
Finally, we took a look at the control of flow constructs that SQL Server offers. By mixing these constructs,
we are able to conditionally execute code, create loops, or provide for a form of string substitution.
In the next couple of chapters, we will take the notions of scripting and batches to the next level, and
apply them to stored procedures, user-defined functions, and triggers — the closest things that SQL
Server has to actual programs.