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

Chapter 11: Writing Scripts and Batches
recognize keywords, but also understand their nature. In addition, you have Intellisense, a step debugger,
code templates, the object browser, and more.
Scripts are usually treated as a unit. That is, you are normally executing the entire script or nothing at all.
They can make use of both system functions and local variables. As an example, let’s look at a script that
would insert order records in the Accounting database that we created back in Chapter 5:
USE Accounting;
DECLARE @Ident int;
INSERT INTO Orders
(CustomerNo,OrderDate, EmployeeID)
VALUES
(1, GETDATE(), 1);
SELECT @Ident = @@IDENTITY;
INSERT INTO OrderDetails
(OrderID, PartNo, Description, UnitPrice, Qty)
VALUES
(@Ident, ‘2R2416’, ‘Cylinder Head’, 1300, 2);
SELECT ‘The OrderID of the INSERTed row is ‘ + CONVERT(varchar(8),@Ident);
If you didn’t keep your populated version of the Accounting database, a script to re-create it in a state
usable for this chapter can be downloaded from the Wrox support Website (wrox.com) or my personal
support site at www.professionalsql.com.
We have six distinct commands working here, covering a range of different things that we might do in a
script. We’re using both system functions and local variables, the USE statement, INSERT statements, and
both assignment and regular versions of the SELECT statement. They are all working in unison to accomplish
one task — to insert complete orders into the database.
The USE Statement
326
The USE statement sets the current database. This affects any place where we are making use of default
values for the database portion of our fully qualified object name. In this particular example, we have
not indicated what database the tables in our INSERT or SELECT statements are from, but, since we’ve
included a USE statement prior to our INSERT and SELECT statements, they will use that database (in
this case, Accounting). Without our USE statement, we would be at the mercy of whoever executes the
script to make certain that the correct database was current when the script was executed.
Don’t take this as meaning that you should always include a USE statement in your
script — it depends on what the purpose of the script is. If your intent is to have a
general-purpose script, then leaving out the USE statement might actually be helpful.
Usually, if you are naming database-specific tables in your script (that is, non-system
tables), then you want to use the USE command. I also find it very helpful if the
script is meant to modify a specific database — as I’ve said in prior chapters, I can’t
tell you how many times I’ve accidentally created a large number of tables in the
master database that were intended for a user database.