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

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

cdn.s3techtraining.com
from cdn.s3techtraining.com More from this publisher
17.06.2013 Views

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

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);

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!