C# 4 and .NET 4

858 ❘ ChaPTer 30 cOre AdO.net
GO
Categories AS new
WHERE old.CategoryID = new.CategoryID;
code download StoredProcs.sql
If you are used to Oracle stored procedures, SQL Server doesn’t exactly have the concept of OLD and NEW
rows; instead, for an insert trigger there is an in-memory table called Inserted, and for deletes and updates
the old rows are available within the Deleted table.
This trigger retrieves the CategoryID of the record(s) affected and stores this together with the old and new
value of the CategoryName column.
Now, when you call your original stored procedure to insert a new CategoryID, you receive an identity
value; however, this is no longer the identity value from the row inserted into the Categories table — it is
now the new value generated for the row in the CategoryAudit table. Ouch!
To view the problem first-hand, open a copy of SQL Server Enterprise Manager, and view the contents of
the Categories table (see Figure 30-11).
figure 30-11
This lists all the categories in the Northwind database.
The next identity value for the Categories table should be 9, so a new row can be inserted by executing the
following code, to see what ID is returned:
DECLARE @CatID int;
EXECUTE CategoryInsert 'Pastries', 'Heaven Sent Food', @CatID OUTPUT;
PRINT @CatID;
The output value of this on a test PC was 1. If you look at the CategoryAudit table shown in
Figure 30-12, you will find that this is the identity of the newly inserted audit record, not the identity of
the category record created.
The problem lies in the way that @@IDENTITY actually
works. It returns the LAST identity value created by your
session, so as shown in Figure 30-12, it isn’t completely
reliable.
figure 30-12
Two other identity functions can be used instead of
@@IDENTITY, but neither is free from possible problems. The first, SCOPE_IDENTITY(), returns the last
identity value created within the current scope. SQL Server defines scope as a stored procedure, trigger, or
function. This may work most of the time, but if for some reason someone adds another INSERT statement
to the stored procedure, you can receive this value rather than the one you expected.
The other identity function, IDENT_CURRENT(), returns the last identity value generated for a given table
in any scope. For example, if two users were accessing SQL Server at exactly the same time, it might be
possible to receive the other user’s generated identity value.
As you might imagine, tracking down a problem of this nature is not easy. The moral of the story is to
beware when using IDENTITY columns in SQL Server.
www.it-ebooks.info