Learn more about SQL Server tools


Latest from MSSQLTips

Properly Capturing Identity Values in a SQL Server Database

MSSQLTips author Armando Prato By:   |   Read Comments (4)   |   Related Tips: 1 | 2 | 3 | 4 | More > Identities

When inserting a row into a database table that contains an identity column, I need a way to capture the identity value generated by the database engine after it inserts the row into this table. What can I use to capture this value while also making sure this value is accurate?

SQL Server provides three different functions for capturing the last generated identity value on a table that contains an identity column:

  • IDENT_CURRENT(‘tablename')

All three functions return the last value inserted into an identity column by the database engine. However, the three differ in functionality depending on the scope (or source) of the insert (i.e. a stored procedure or a trigger) and the connection that inserted the row.

Function @@IDENTITY returns the last generated table identity value for the current connection across all scope (i.e. any called stored procedures and any fired triggers). This function is not table specific. The value returned will be for the last table insert where an identity value was generated.

Function SCOPE_IDENTITY() is identical to @@IDENTITY with the following very notable exception: the value returned is limited to the current scope (i.e. the executed stored procedure).

Finally, function IDENT_CURRENT spans all scope and all connections to retrieve the last generated table identity value. Unlike @@IDENTITY and SCOPE_IDENTITY(), it is table specific and takes a tablename as a parameter.

We'll create an example to illustrate these functions in action.

First, we'll create 2 simple example tables: one table representing a customer table and another representing an audit table. The audit table's purpose is to track all inserts and deletes of customers to/from the database.

CREATE TABLE dbo.customer 

CREATE TABLE dbo.auditlog 
customerid INTaction CHAR(1), 
changedate datetime DEFAULT GETDATE())

Second, we'll create an example stored procedure that inserts a customer row and returns the generated identity value along with a supporting trigger on customer that inserts a row into our audit table:

CREATE PROCEDURE dbo.p_InsertCustomer @customerid INT output
nocount ON
dbo.customer DEFAULT VALUES
@customerid @@identity

CREATE TRIGGER dbo.tr_customer_log ON dbo.customer
EXISTS (SELECT 'x' FROM inserted)
INSERT INTO dbo.auditlog (customeridaction
SELECT customerid'I' 
FROM inserted
EXISTS (SELECT 'x' FROM deleted)
INSERT INTO dbo.auditlog (customeridaction
SELECT customerid'D' 
FROM deleted

Now we're ready to execute our procedure so we can create our first customer row:

DECLARE @customerid INT
dbo.p_InsertCustomer @customerid output
SELECT @customerid AS customerid

We returned the expected value for the first customer and we've logged an entry for the insert into our audit table. So far, the data looks good.

Imagine that a customer service rep needs to delete this newly entered customer from the database due to some miscommunication. Let's delete the inserted customer row:

DELETE FROM dbo.customer WHERE customerid 1

At this point, the customer table is empty and the audit table has 2 rows - one for the first insert and a second for the delete of the customer. So far, so good.

Now, let's add a 2nd customer to our database and examine the captured identity value:

DECLARE @customerid INT
dbo.p_InsertCustomer @customerid output
SELECT @customerid AS customerid

Whoa! What happened here? If we examine the customer table, we'll see that customer 2 was created, but our procedure is returning 3! What's going on here? Well recall that earlier in this tip, it's mentioned that @@IDENTITY spans scope. What this means is that it will return the last identity value generated from any stored procedure that was called by the main procedure or by any trigger that was fired - whichever generates an identity value last prior to the function being invoked. In our example, the primary scope is p_InsertCustomer and the secondary scope is the trigger tr_customer_log which was fired to record the insert. As a result, we're getting the identity value generated by the trigger insert on the auditlog table and not the one we're expecting on customer.

Prior to SQL Server 2000, the @@IDENTITY function was the only way to capture identity values. Due to this stored procedure/trigger issue, the SQL Server development team introduced both SCOPE_IDENTITY() and IDENT_CURRENT in SQL Server 2000 to mitigate this. In older versions of SQL Server, there was no easy workaround. In SQL Server 6.5, I would sometimes remove the identity from the column and create a supporting table that would hold the next value to use in effect mimicking the behavior of the identity column. It was an ugly kludge to say the least.

Let's alter our stored procedure to use SCOPE_IDENTITY() and re-execute the procedure to add a 3rd customer:

ALTER PROCEDURE dbo.p_InsertCustomer @customerid INT output 
nocount ON 
dbo.customer DEFAULT VALUES 
@customerid SCOPE_IDENTITY()

DECLARE @customerid INT
dbo.p_InsertCustomer @customerid output
SELECT @customerid AS customerid

Now, we get 3 again but this time it's correct! We've added customer 3. If we examine the auditlog table, we'll see a 4th entry that records the newly inserted customer. Since SCOPE_IDENTITY() does not span scope and is relegated to only capturing values based on execution of the current procedure (the current scope), we've eliminated our identity capture issue.

As mentioned earlier, both @@IDENTITY and SCOPE_IDENTITY() are not table specific, unlike IDENT_CURRENT which can take a table parameter. Using @@IDENTITY or SCOPE_IDENTITY() requires careful placement within your code, so the appropriate identity value is captured from the intended table. On its surface, it would appear safer to forego both SCOPE_IDENTITY() and @@IDENTITY and instead use IDENT_CURRENT and specify a table. That should solve any issues with inaccurate capturing of identity values, right? Recall that I mentioned that IDENT_CURRENT not only spans scope, but it also spans connections. In other words, the value generated by IDENT_CURRENT is not confined to the processing done within your connection, but also spans all connections across the entire database. As a result, even in a moderately active OLTP environment there is a real concern about reliability of the value returned by this function. The value you capture may not necessarily be accurate which could lead to data corruption issues similar to the @@IDENTITY/trigger issue presented in this tip.

My opinion is that SCOPE_IDENTITY() is the safest function of the three and should be your default choice to be used over @@IDENTITY and IDENT_CURRENT. By using SCOPE_IDENTITY() you can safely add triggers and sub procedures without inadvertently corrupting your data. Furthermore, both @@IDENTITY and IDENT_CURRENT should be reserved for very specialized business cases (if at all - I've never come across a business case that required the use of either one over SCOPE_IDENTITY). In those cases where you find you require either, their use should be properly documented and carefully tested due to the nature of their behavior (i.e. the range of their scope and their range of connection).

Next Steps

  • Examine your database logic for references to @@IDENTITY and consider changing this logic to reference SCOPE_IDENTITY()
  • Examine your database logic for any references to IDENT_CURRENT and make sure its use is confined to single user processing. Consider using SCOPE_IDENTITY() instead.
  • Read more about @@IDENTITY, SCOPE_IDENTITY, and IDENT_CURRENT in the SQL Server 2000 and 2005 Books Online

Last Update: 1/2/2008

About the author
MSSQLTips author Armando Prato
Armando Prato has close to 30 years of industry experience and has been working with SQL Server since version 6.5.

View all my tips

print tip Print  
Become a paid author

Learn more about SQL Server tools

Post a comment or let the author know this tip helped you.

       All comments are reviewed, so stay on subject or we may delete your comment.

*Name   *Email Notify for updates

       Note: your email address is not published. Required fields are marked with an asterisk (*)

Get free SQL tips:

*Enter Code refresh code     

Tuesday, August 12, 2008 - 11:41:30 AM - aprato Read The Tip

The value for SCOPE_IDENTITY() is stored in memory (as is @@IDENTITY for that matter).  The SQL statement is grabbing the value right from memory.

In the simple script below, displaying the execution plan shows that 70% of the batch is working with the OUTPUT approach to capturing an identity while the remaining 30% is attributed to the scope_identity() approach.  Each proc inserts 1 row.

set nocount on

if object_id('test') is not null
   drop table test
create table test (id int identity)

if object_id('test1') is not null
   drop proc test1; 
if object_id('test2') is not null
   drop proc test2;

create proc test1
set nocount on

  declare @temp table (id int)
  declare @id int

  insert into test output inserted.id into @temp(id) default values
  select @id = id from @temp
  print cast(@id as varchar)


create proc test2
  set nocount on

  insert into test default values
  print cast (scope_identity() as varchar)


truncate table test
exec test1
truncate table test
exec test2

Monday, August 11, 2008 - 10:32:32 AM - RDWilson2 Read The Tip

However, the use of SCOPE_IDENTITY() requires an addition SQL statement execution.  While this may not seem like a lot of time, it can add up if you are doing a few million insertions.

To me, the use of the OUTPUT clause seems much simpler than setting up and executing an additional SQL statement.  It also precludes any confusion over exactly which Identity retrieval method to use.

 However, that's just me and you are certainly entitled to use whichever approach suits you best (and works best for ou).

Friday, August 08, 2008 - 9:17:53 PM - aprato Read The Tip

While you could use OUTPUT clauses, I prefer the simplicity of SCOPE_IDENTITY(); I don't have to build a structure to capture the id value and then SELECT it out. :)

OUTPUT clauses are great for sending data to a secondary table. In fact, I just used it in an archiving stored procedure where I DELETE from the current table and OUTPUT directly to the history table. 

Friday, August 08, 2008 - 6:32:29 PM - RDWilson2 Read The Tip

The really great news is that there is a new way to get the Identity value returned if you are using SQL Server 2005 . . . check out the OUT variables that you can use during an INSERT statement.  You can return the ID column or anything else (even the whole bloody record ;-).

More SQL Server Solutions



Get Free SQL Tips










BI Professionals


Q and A

Today's Tip







Tip Categories

Search By TipID



First Timer?


Free T-shirt



User Groups

Author of the Year

More Info








Copyright (c) 2006-2015 Edgewood Solutions, LLC All rights reserved
Some names and products listed are the registered trademarks of their respective owners.