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

Using @@IDENTITY
@@IDENTITY is one of the most important of all the system functions. An identity column is one where
we don’t supply a value, and SQL Server inserts a numbered value automatically.
In our example case, we obtain the value of @@IDENTITY right after performing an insert into the Orders
table. The issue is that we don’t supply the key value for that table — it’s automatically created as we do
the insert. Now we want to insert a record into the OrderDetails table, but we need to know the value
of the primary key in the associated record in the Orders table (remember, there is a foreign key constraint
on the OrderDetails table that references the Orders table). Because SQL Server generated that value
instead of us supplying it, we need to have a way to retrieve that value for use in our dependent inserts
later on in the script. @@IDENTITY gives us that automatically generated value because it was the last
statement run.
In this example, we could have easily gotten away with not moving @@IDENTITY to a local variable —
we could have just referenced it explicitly in our next INSERT query. I make a habit of always moving it
to a local variable, however, to avoid errors on the occasions when I do need to keep a copy. An example
of this kind of situation would be if we had yet another INSERT that was dependent on the identity value
from the INSERT into the Orders table. If I hadn’t moved it into a local variable, then it would be lost when
I did the next INSERT, because it would have been overwritten with the value from the OrderDetails
table, which, since OrderDetails has no identity column, means that @@IDENTITY would have been set
to NULL. Moving the value of @@IDENTITY to a local variable also let me keep the value around for the
statement where I printed out the value for later reference.
Let’s create a couple of tables to try this out:
CREATE TABLE TestIdent
(
IDCol int IDENTITY
PRIMARY KEY
);
CREATE TABLE TestChild1
(
IDcol int
PRIMARY KEY
FOREIGN KEY
REFERENCES TestIdent(IDCol)
);
CREATE TABLE TestChild2
(
IDcol int
PRIMARY KEY
FOREIGN KEY
REFERENCES TestIdent(IDCol)
);
Chapter 11: Writing Scripts and Batches
What we have here is a parent table — it has an identity column for a primary key (as it happens, that’s
the only column it has). We also have two child tables. They each are the subject of an identifying relationship
— that is, they each take at least part (in this case all) of their primary key by placing a foreign
331