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

Chapter 11: Writing Scripts and Batches
ELSE
PRINT ‘The value currently in @@IDENTITY is ‘ + CONVERT(varchar(2),@@IDENTITY);
-- The next line is just a spacer for our print out
PRINT ‘’;
/* This time all will go fine because we are using the value that
** we have placed in safekeeping instead of @@IDENTITY directly.*/
INSERT INTO TestChild2
VALUES
(@Ident);
This time everything runs just fine:
(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
(1 row(s) affected)
Using @@ROWCOUNT
334
In this example, it was fairly easy to tell that there was a problem because of the
attempt at inserting a NULL into the primary key. Now, imagine a far less pretty scenario
— one where the second table did have an identity column. You could easily
wind up inserting bogus data into your table and not even knowing about it — at
least not until you already had a very serious data integrity problem on your hands!
In the many queries that we ran up to this point, it’s always been pretty easy to tell how many rows a
statement affected — the Query window tells us. For example, if we run:
USE AdventureWorks2008
SELECT * FROM Person.Person;
then we see all the rows in Person, but we also see a count on the number of rows affected by our query
(in this case, it’s all the rows in the table):
(19972 row(s) affected)
But what if we need to programmatically know how many rows were affected? Much like @@IDENITY,
@@ROWCOUNT is an invaluable tool in the fight to know what’s going on as your script runs — but this
time the value is how many rows were affected rather than our identity value.
Let’s examine this just a bit further with an example:
USE AdventureWorks2008;
GO