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

Chapter 11: Writing Scripts and Batches
If your table names went into the DynamicSQLExample table the way mine did, then a TableID of 25
should equate to the Production.UnitMeasure table. If so, you should wind up with something like
this (the rightmost columns have been snipped for brevity):
UnitMeasureCode Name ModifiedDate
--------------- ---------------------- -----------------------
BOX Boxes 1998-06-01 00:00:00.000
BTL Bottle 1998-06-01 00:00:00.000
C Celsius 1998-06-01 00:00:00.000
…
…
PC Piece 1998-06-01 00:00:00.000
PCT Percentage 1998-06-01 00:00:00.000
PT Pint, US liquid 1998-06-01 00:00:00.000
(38 row(s) affected)
The Gotchas of EXEC
Like most things that are of interest, using EXEC is not without its little trials and tribulations. Among
the gotchas of EXEC are:
❑ It runs under a separate scope than the code that calls it — that is, the calling code can’t reference
variables inside the EXEC statement, and the EXEC can’t reference variables in the calling
code after they are resolved into the string for the EXEC statement. If you need to pass values
between your dynamic SQL and the routine that calls it, consider using sp_executesql.
❑ By default, it runs under the same security context as the current user — not that of the calling
object (an object generally runs under the context of the object’s owner, not the current user).
❑ It runs under the same connection and transaction context as the calling object (we’ll discuss
this further in Chapter 14).
❑ Concatenation that requires a function call must be performed on the EXEC string prior to actually
calling the EXEC statement — you can’t do the concatenation of function in the same statement
as the EXEC call.
❑ EXEC cannot be used inside a user-defined function.
Each of these can be a little difficult to grasp, so let’s look at each individually.
The Scope of EXEC
346
Determining variable scope with the EXEC statement is something less than intuitive. The actual statement
line that calls the EXEC statement has the same scope as the rest of the batch or procedure that the
EXEC statement is running in, but the code that is performed as a result of the EXEC statement is considered
to be in its own batch. As is so often the case, this is best shown with an example:
USE AdventureWorks2008;
/* First, we’ll declare to variables. One for stuff we’re putting into
** the EXEC, and one that we think will get something back out (it won’t)
*/