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 key on another table (the parent). So what we have is a situation where the two child tables need to get their key from the parent. Therefore, we need to insert a record into the parent first, and then retrieve the identity value generated so we can make use of it in the other tables. Try It Out Using @@IDENTITY 332 Now that we have some tables to work with, we’re ready to try a little test script: /***************************************** ** This script illustrates how the identity ** value gets lost as soon as another INSERT ** happens ****************************************** */ DECLARE @Ident int; -- This will be a holding variable /* We’ll use it to show how we can ** move values from system functions ** into a safe place. */ INSERT INTO TestIdent DEFAULT VALUES; SET @Ident = @@IDENTITY; PRINT ‘The value we got originally from @@IDENTITY was ‘ + CONVERT(varchar(2),@Ident); PRINT ‘The value currently in @@IDENTITY is ‘ + CONVERT(varchar(2),@@IDENTITY); /* On this first INSERT using @@IDENTITY, we’re going to get lucky. ** We’ll get a proper value because there is nothing between our ** original INSERT and this one. You’ll see that on the INSERT that ** will follow after this one, we won’t be so lucky anymore. */ INSERT INTO TestChild1 VALUES (@@IDENTITY); PRINT ‘The value we got originally from @@IDENTITY was ‘ + CONVERT(varchar(2),@Ident); IF (SELECT @@IDENTITY) IS NULL PRINT ‘The value currently in @@IDENTITY is NULL’; ELSE PRINT ‘The value currently in @@IDENTITY is ‘ + CONVERT(varchar(2),@@IDENTITY); -- The next line is just a spacer for our print out PRINT ‘’; /* The next line is going to blow up because the one column in ** the table is the primary key, and primary keys can’t be set ** to NULL. @@IDENTITY will be NULL because we just issued an ** INSERT statement a few lines ago, and the table we did the ** INSERT into doesn’t have an identity field. Perhaps the biggest ** thing to note here is when @@IDENTITY changed - right after ** the next INSERT statement. */ INSERT INTO TestChild2 VALUES (@@IDENTITY);
How It Works What we’re doing in this script is seeing what happens if we depend on @@IDENTITY directly rather than moving the value to a safe place. When we execute the preceding script, everything’s going to work just fine until the final INSERT. That final statement is trying to make use of @@IDENTITY directly, but the preceding INSERT statement has already changed the value in @@IDENTITY. Because that statement is on a table with no identity column, the value in @@IDENTITY is set to NULL. Because we can’t have a NULL value in our primary key, the last INSERT fails: (1 row(s) affected) The value we got originally from @@IDENTITY was 1 The value currently in @@IDENTITY is 1 (1 row(s) affected) The value we got originally from @@IDENTITY was 1 The value currently in @@IDENTITY is NULL Msg 515, Level 16, State 2, Line 41 Cannot insert the value NULL into column ‘IDcol’, table ‘Accounting.dbo.TestChild2’; column does not allow nulls. INSERT fails. The statement has been terminated. If we make just one little change (to save the original @@IDENTITY value): /***************************************** ** This script illustrates how the identity ** value gets lost as soon as another INSERT ** happens ****************************************** */ DECLARE @Ident int; -- This will be a holding variable /* We’ll use it to show how we can ** move values from system functions ** into a safe place. */ INSERT INTO TestIdent DEFAULT VALUES; SET @Ident = @@IDENTITY; PRINT ‘The value we got originally from @@IDENTITY was ‘ + CONVERT(varchar(2),@Ident); PRINT ‘The value currently in @@IDENTITY is ‘ + CONVERT(varchar(2),@@IDENTITY); /* On this first INSERT using @@IDENTITY, we’re going to get lucky. ** We’ll get a proper value because there is nothing between our ** original INSERT and this one. You’ll see that on the INSERT that ** will follow after this one, we won’t be so lucky anymore. */ INSERT INTO TestChild1 VALUES (@@IDENTITY); PRINT ‘The value we got originally from @@IDENTITY was ‘ + CONVERT(varchar(2),@Ident); IF (SELECT @@IDENTITY) IS NULL PRINT ‘The value currently in @@IDENTITY is NULL’; Chapter 11: Writing Scripts and Batches 333
- Page 319 and 320: works only if tempdb is on a separa
- Page 321 and 322: Secondary XML Indexes Chapter 9: SQ
- Page 323 and 324: occur, and that one or more non-lea
- 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: Using @@IDENTITY @@IDENTITY is one
- Page 373 and 374: DECLARE @RowCount int; --Notice the
- Page 375 and 376: When the editing tool encounters a
- Page 377 and 378: When you think about it, this seems
- 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
Chapter 11: Writing Scripts and Batches<br />
key on another table (the parent). So what we have is a situation where the two child tables need to get<br />
their key from the parent. Therefore, we need to insert a record into the parent first, and then retrieve the<br />
identity value generated so we can make use of it in the other tables.<br />
Try It Out Using @@IDENTITY<br />
332<br />
Now that we have some tables to work with, we’re ready to try a little test script:<br />
/*****************************************<br />
** This script illustrates how the identity<br />
** value gets lost as soon as another INSERT<br />
** happens<br />
****************************************** */<br />
DECLARE @Ident int; -- This will be a holding variable<br />
/* We’ll use it to show how we can<br />
** move values from system functions<br />
** into a safe place.<br />
*/<br />
INSERT INTO TestIdent<br />
DEFAULT VALUES;<br />
SET @Ident = @@IDENTITY;<br />
PRINT ‘The value we got originally from @@IDENTITY was ‘ +<br />
CONVERT(varchar(2),@Ident);<br />
PRINT ‘The value currently in @@IDENTITY is ‘ + CONVERT(varchar(2),@@IDENTITY);<br />
/* On this first INSERT using @@IDENTITY, we’re going to get lucky.<br />
** We’ll get a proper value because there is nothing between our<br />
** original INSERT and this one. You’ll see that on the INSERT that<br />
** will follow after this one, we won’t be so lucky anymore. */<br />
INSERT INTO TestChild1<br />
VALUES<br />
(@@IDENTITY);<br />
PRINT ‘The value we got originally from @@IDENTITY was ‘ +<br />
CONVERT(varchar(2),@Ident);<br />
IF (SELECT @@IDENTITY) IS NULL<br />
PRINT ‘The value currently in @@IDENTITY is NULL’;<br />
ELSE<br />
PRINT ‘The value currently in @@IDENTITY is ‘ + CONVERT(varchar(2),@@IDENTITY);<br />
-- The next line is just a spacer for our print out<br />
PRINT ‘’;<br />
/* The next line is going to blow up because the one column in<br />
** the table is the primary key, and primary keys can’t be set<br />
** to NULL. @@IDENTITY will be NULL because we just issued an<br />
** INSERT statement a few lines ago, and the table we did the<br />
** INSERT into doesn’t have an identity field. Perhaps the biggest<br />
** thing to note here is when @@IDENTITY changed - right after<br />
** the next INSERT statement. */<br />
INSERT INTO TestChild2<br />
VALUES<br />
(@@IDENTITY);