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

Chapter 11: Writing Scripts and Batches
If you decide to use a temp table to communicate between scopes, just remember that any temporary
table created within the scope of your EXEC statement will only live for the life of that EXEC statement.
A Small Exception to the Rule
There is one thing that happens inside the scope of the EXEC that can be seen after the EXEC is done —
system functions — so, things like @@ROWCOUNT can still be used. Again, let’s look at a quick example:
USE AdventureWorks2008;
EXEC(‘SELECT * FROM Production.UnitMeasure’);
SELECT ‘The Rowcount is ‘ + CAST(@@ROWCOUNT as varchar);
This yields (after the result set):
The Rowcount is 38
Security Contexts and EXEC
This is a tough one to cover at this point because we haven’t covered the issues yet with stored procedures
and security. Still, the discussion of the EXEC command belonged here rather than in the sprocs chapter, so
here we are (this is the only part of this discussion that gets wrapped up in sprocs, so bear with me).
When you give someone the right to run a stored procedure, you imply that they also gain the right to
perform the actions called for within the sproc. For example, let’s say we had a stored procedure that lists
all the employees hired within the last year. Someone who has rights to execute the sproc can do so (and
get results back) even if they do not have rights to the Employees table directly. This is really handy for
reasons we will explore later in our sprocs chapter.
Developers usually assume that this same implied right is valid for an EXEC statement also — it isn’t. Any
reference made inside an EXEC statement will, by default, be run under the security context of the current
user. So, let’s say I have the right to run a procedure called spNewEmployees, but I do not have rights to
the Employees table. If spNewEmployees gets the values by running a simple SELECT statement, then
everything is fine. If, however, spNewEmployees uses an EXEC statement to execute that SELECT statement,
the EXEC statement will fail because I don’t have the rights to perform a SELECT on the Employees table.
Since we don’t have that much information on sprocs yet, I’m going to bypass further discussion of this
for now, but we will come back to it when we discuss sprocs later on.
Use of Functions in Concatenation and EXEC
348
This behavior of a temp table only lasting the life of your EXEC procedure will show
up again when we are dealing with triggers and sprocs.
This one is actually more of a nuisance than anything else because there is a reasonably easy workaround.
Simply put, you can’t run a function against your EXEC string in the argument for an EXEC. For example:
USE AdventureWorks2008;