Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
Beginning Microsoft SQL Server 2008 ... - S3 Tech Training Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
Chapter 11: Writing Scripts and Batches Using Batches to Establish Precedence 338 Note that, if you DROP an object, you may want to place the DROP in its own batch or at least with a batch of other DROP statements. Why? Well, if you’re going to later create an object with the same name, the CREATE will fail during the parsing of your batch unless the DROP has already happened. That means you need to run the DROP in a separate and prior batch so it will be complete when the batch with the CREATE statement executes. Perhaps the most likely scenario for using batches is when precedence is required — that is, you need one task to be completely done before the next task starts. Most of the time, SQL Server deals with this kind of situation just fine — the first statement in the script is the first executed, and the second statement in the script can rely on the server being in the proper state when the second statement runs. There are times, however, when SQL Server can’t resolve this kind of issue. Let’s take the example of creating a database together with some tables: USE master; CREATE DATABASE Test; CREATE TABLE TestTable ( col1 int, col2 int ); Execute this and, at first, it appears that everything has gone well: Command(s) completed successfully. However, things are not as they seem — check out the INFORMATION_SCHEMA in the Test database: USE Test; SELECT TABLE_CATALOG FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = ‘TestTable’; And you'll notice something is missing: TABLE_CATALOG -------------------- AdventureWorks2008 (1 row(s) affected) Hey! Why was the table created in the wrong database? The answer lies in what database was current when we ran the CREATE TABLE statement. In my case, it happened to be the master database, so that’s where my table was created. Note that you may have been somewhere other than the master database when you ran this, so you may get a different result. That’s kind of the point though — you could be in pretty much any database. That’s why making use of the USE statement is so important.
When you think about it, this seems like an easy thing to fix — just make use of the USE statement, but before we test our new theory, we have to get rid of the old (OK, not that old) database: USE MASTER; DROP DATABASE Test; We can then run our newly modified script: CREATE DATABASE Test; USE Test; CREATE TABLE TestTable ( col1 int, col2 int ); Unfortunately, this has its own problems: Msg 911, Level 16, State 1, Line 3 Database ‘Test’ does not exist. Make sure that the name is entered correctly. The parser tries to validate your code and finds that you are referencing a database with your USE command that doesn’t exist. Ahh, now we see the need for our batches. We need the CREATE DATABASE statement to be completed before we try to use the new database: CREATE DATABASE Test; GO USE Test; CREATE TABLE TestTable ( col1 int, col2 int ); Now things work a lot better. Our immediate results look the same: Command(s) completed successfully. But when we run our INFORMATION_SCHEMA query, things are confirmed: TABLE_CATALOG -------------------- Test (1 row(s) affected) Chapter 11: Writing Scripts and Batches Let’s move on to another example that shows an even more explicit need for precedence. When you use an ALTER TABLE statement that significantly changes the type of a column or adds columns, you cannot make use of those changes until the batch that makes the changes has completed. 339
- Page 325 and 326: isn’t room on the page, SQL Serve
- Page 327 and 328: more administrator oriented and usu
- Page 329 and 330: The Database Engine Tuning Advisor
- Page 331 and 332: The output is far more self-describ
- Page 333 and 334: We use a FILLFACTOR when we need to
- Page 335: Chapter 9: SQL Server Storage and I
- Page 338 and 339: Chapter 10: Views The preceding syn
- Page 340 and 341: Chapter 10: Views 302 columns to a
- Page 342 and 343: Chapter 10: Views Try It Out Using
- Page 344 and 345: Chapter 10: Views 306 soh.SalesOrde
- Page 346 and 347: Chapter 10: Views AW00000676 43659
- Page 348 and 349: Chapter 10: Views NULL values will
- Page 350 and 351: Chapter 10: Views Editing V iews wi
- Page 352 and 353: Chapter 10: Views 314 There are fou
- Page 354 and 355: Chapter 10: Views Editing Views in
- Page 356 and 357: Chapter 10: Views 318 In addition,
- Page 358 and 359: Chapter 10: Views 320 from the firs
- Page 360 and 361: Chapter 10: Views You can get the y
- Page 363 and 364: 11 Writing Scripts and Batches Whet
- Page 365 and 366: Next we have a DECLARE statement to
- Page 367 and 368: I’m not going to pick any bones a
- Page 369 and 370: Using @@IDENTITY @@IDENTITY is one
- Page 371 and 372: How It Works What we’re doing in
- Page 373 and 374: DECLARE @RowCount int; --Notice the
- Page 375: When the editing tool encounters a
- Page 379 and 380: So, let’s try a quick query direc
- Page 381 and 382: We now have our text file source fo
- Page 383 and 384: Let’s build an example in the Adv
- Page 385 and 386: DECLARE @InVar varchar(50); DECLARE
- Page 387 and 388: -- This won’t work DECLARE @Numbe
- Page 389 and 390: -- Now we’re run our conditional
- Page 391 and 392: Out of the condition from inner con
- Page 393 and 394: A Simple CASE A simple CASE takes a
- Page 395 and 396: 3 8 More Than One Apart 2 2 Ends Wi
- Page 397 and 398: Now, I don’t know about you, but
- Page 399 and 400: The WAITFOR statement does exactly
- Page 401 and 402: IF @ErrorNo = 2714 -- Object exists
- Page 403: Chapter 11: Writing Scripts and Bat
- Page 406 and 407: Chapter 12: Stored Procedures Creat
- Page 408 and 409: Chapter 12: Stored Procedures Dropp
- Page 410 and 411: Chapter 12: Stored Procedures Suppl
- Page 412 and 413: Chapter 12: Stored Procedures 374 [
- Page 414 and 415: Chapter 12: Stored Procedures Confi
- Page 416 and 417: Chapter 12: Stored Procedures Now,
- Page 418 and 419: Chapter 12: Stored Procedures SQL S
- Page 420 and 421: Chapter 12: Stored Procedures 382 c
- Page 422 and 423: Chapter 12: Stored Procedures It wo
- Page 424 and 425: Chapter 12: Stored Procedures 386 r
Chapter 11: Writing Scripts and Batches<br />
Using Batches to Establish Precedence<br />
338<br />
Note that, if you DROP an object, you may want to place the DROP in its own batch or at<br />
least with a batch of other DROP statements. Why? Well, if you’re going to later create an<br />
object with the same name, the CREATE will fail during the parsing of your batch unless<br />
the DROP has already happened. That means you need to run the DROP in a separate and<br />
prior batch so it will be complete when the batch with the CREATE statement executes.<br />
Perhaps the most likely scenario for using batches is when precedence is required — that is, you need<br />
one task to be completely done before the next task starts. Most of the time, <strong>SQL</strong> <strong>Server</strong> deals with this<br />
kind of situation just fine — the first statement in the script is the first executed, and the second statement<br />
in the script can rely on the server being in the proper state when the second statement runs. There are<br />
times, however, when <strong>SQL</strong> <strong>Server</strong> can’t resolve this kind of issue.<br />
Let’s take the example of creating a database together with some tables:<br />
USE master;<br />
CREATE DATABASE Test;<br />
CREATE TABLE TestTable<br />
(<br />
col1 int,<br />
col2 int<br />
);<br />
Execute this and, at first, it appears that everything has gone well:<br />
Command(s) completed successfully.<br />
However, things are not as they seem — check out the INFORMATION_SCHEMA in the Test database:<br />
USE Test;<br />
SELECT TABLE_CATALOG<br />
FROM INFORMATION_SCHEMA.TABLES<br />
WHERE TABLE_NAME = ‘TestTable’;<br />
And you'll notice something is missing:<br />
TABLE_CATALOG<br />
--------------------<br />
AdventureWorks<strong>2008</strong><br />
(1 row(s) affected)<br />
Hey! Why was the table created in the wrong database? The answer lies in what database was current<br />
when we ran the CREATE TABLE statement. In my case, it happened to be the master database, so that’s<br />
where my table was created.<br />
Note that you may have been somewhere other than the master database when you ran this, so you may<br />
get a different result. That’s kind of the point though — you could be in pretty much any database.<br />
That’s why making use of the USE statement is so important.