Reset identity seed after deleting records in SQL Server

I have inserted records into a SQL Server database table. The table had a primary key defined and the auto increment identity seed is set to “Yes”. This is done primarily because in SQL Azure, each table has to have a primary key and identity defined.

But since I have to delete some records from the table, the identity seed for those tables will be disturbed and the index column (which is auto-generated with an increment of 1) will get disturbed.

**How can I reset the identity column after I deleted the records so that the column has sequence in ascending numerical order?**

The identity column is not used as a foreign key anywhere in database.

This is a common question and the answer is always the same: don't do it. Identity values should be treated as arbitrary and, as such, there is no "correct" order.

Run this script to reset the identity column. You will need to make two changes. Replace tableXYZ with whatever table you need to update. Also, the name of the identity column needs dropped from the temp table. This was instantaneous on a table with 35,000 rows & 3 columns. Obviously, backup the table and first try this in a test environment.

---------------------------------------------

select *
into #temp
From tableXYZ

set identity_insert tableXYZ ON

truncate table tableXYZ

alter table #temp drop column (nameOfIdentityColumn)

set identity_insert tableXYZ OFF

insert into tableXYZ
select * from #temp

It should be noted that IF _all_ of the data is being removed from the table via the `DELETE` (i.e. no `WHERE` clause), then as long as a) permissions allow for it, and b) there are no FKs referencing the table (which appears to be the case here), using `TRUNCATE TABLE` would be preferred as it does a more efficient `DELETE` _and_ resets the `IDENTITY` seed at the same time. The following details are taken from the MSDN page for [TRUNCATE TABLE][1]:

> Compared to the DELETE statement, TRUNCATE TABLE has the following advantages:
>
> * Less transaction log space is used.
>
> The DELETE statement removes rows one at a time and records an entry in the transaction log for each deleted row. TRUNCATE TABLE removes the data by deallocating the data pages used to store the table data and records only the page deallocations in the transaction log.
>
> * Fewer locks are typically used.
>
> When the DELETE statement is executed using a row lock, each row in the table is locked for deletion. TRUNCATE TABLE always locks the table (including a schema (SCH-M) lock) and page but not each row.
>
> * Without exception, zero pages are left in the table.
>
> After a DELETE statement is executed, the table can still contain empty pages. For example, empty pages in a heap cannot be deallocated without at least an exclusive (LCK_M_X) table lock. If the delete operation does not use a table lock, the table (heap) will contain many empty pages. For indexes, the delete operation can leave empty pages behind, although these pages will be deallocated quickly by a background cleanup process.
>
> If the table contains an identity column, the counter for that column is reset to the seed value defined for the column. If no seed was defined, the default value 1 is used. To retain the identity counter, use DELETE instead.

So the following:

DELETE FROM [MyTable];
DBCC CHECKIDENT ('[MyTable]', RESEED, 0);

Becomes just:

TRUNCATE TABLE [MyTable];

Please see the `TRUNCATE TABLE` documentation (linked above) for additional information on restrictions, etc.

[1]:

[To see links please register here]

DBCC CHECKIDENT ('TestTable', RESEED, 0)
GO

Where 0 is `identity` Start value

Although most answers are suggesting `RESEED` to `0`, and while some see this as a flaw for `TRUNCATED` tables, Microsoft has a solution that excludes the `ID`

DBCC CHECKIDENT ('[TestTable]', RESEED)

This will check the table and reset to the next `ID`. This has been available since MS SQL 2005 to current.

[To see links please register here]

Its always better to use **TRUNCATE** when possible instead of deleting all records as it doesn't use log space also.

In case we need delete and need to reset the seed, always remember that if table was never populated and you used `DBCC CHECKIDENT('tablenem',RESEED,0)`
then first record will get identity = 0
as stated on [msdn documentation][1]

> In your case only **rebuild the index** and don't worry about losing the
> series of identity as this is a common scenario.


[1]:

[To see links please register here]

DBCC CHECKIDENT (<TableName>, reseed, 0)

This will set the current identity value to 0.

On inserting the next value, the identity value get incremented to 1.

issuing 2 command can do the trick

DBCC CHECKIDENT ('[TestTable]', RESEED,0)
DBCC CHECKIDENT ('[TestTable]', RESEED)

the first reset the identity to zero , and the next will set it to the next available value
-- jacob

@jacob

DBCC CHECKIDENT ('[TestTable]', RESEED,0)
DBCC CHECKIDENT ('[TestTable]', RESEED)

Worked for me, I just had to clear all entries first from the table, then added the above in a trigger point after delete. Now whenever i delete an entry is taken from there.