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

Chapter 11: Writing Scripts and Batches
AW00000227 43662 2007-10-06 00:00:00.000 755 Road-450 Red, 60
1 874.7940
0.0000 874.794000
(51 rows affected)
C:\>
How It Works
We started out by bundling the SQL commands we would need into a single script — first, the USE command,
and then the actual SELECT statement.
We then executed our statement using sqlcmd. The –U and –P commands provided the login username
and password information just as they did earlier in the chapter. The –i parameter told sqlcmd that we
had an input file, and we included that file name immediately following the –i parameter. Finally, we
included the –o parameter to tell sqlcmd that we wanted the output written to a file (we, of course, then
provided a file name — YesterdaysOrders.txt). Don’t get confused by the two files both named
YesterdaysOrders — they are separate files with the .sql and .txt files separating what their particular
use is for.
There is a wide variety of different parameters for sqlcmd, but the most important are the login, the password,
and the one that says what you want to do (straight query or input file). You can mix and match many of these
parameters to obtain fairly complex behavior from this seemingly simple command-line tool.
Dynamic SQL: Generating Y our Code On
the Fly with the EXEC Command
OK, so all this saving stuff away in scripts is all fine and dandy, but what if you don’t know what code
you need to execute until runtime?
As a side note, notice that we are done with sqlcmd for now — the following examples should be run
utilizing the Management Console.
SQL Server allows us, with a few gotchas, to build our SQL statement on-the-fly using string manipulation.
The need to do this usually stems from not being able to know the details about something until
runtime. The syntax looks like this:
Or:
344
EXEC ({|’’})
EXECUTE ({|’’})
As with executing a stored proc, whether you use the EXEC or EXECUTE makes no difference.