50

I've got a strange situation with some tables in my database starting its IDs from 0, even though TABLE CREATE has IDENTITY(1,1). This is so for some tables, but not for others. It has worked until today.

I've tried resetting identity column:

DBCC CHECKIDENT (SyncSession, reseed, 0);

But new records start with 0. I have tried doing this for all tables, but some still start from 0 and some from 1.

Any pointers?

(i'm using SQL Server Express 2005 with Advanced Services)

Gert Arnold
  • 105,341
  • 31
  • 202
  • 291
Muxa
  • 5,563
  • 6
  • 46
  • 56
  • There is something wrong with your design if you are constantly reseeding the value. And why should it matter if it starts with 0 or 1? It's an autoincrement, it shouldn't matter what the value is just that it is unique and automatically assigned. – HLGEM Jun 18 '10 at 17:47
  • 2
    Five years late to the party but - like me - the OP could have just been developing and testing with a known set of data. Not necessarily anything wrong with the design. – GeoffM Feb 25 '15 at 18:21
  • 3
    @HLGEM - here's why it maters. if you are populating a code object from a database record, the object will initialize with an "ID" property of 0. Then if the populating is successful it will be something other than the default of 0. 0 can then indicate no record found or a "new" object. – nuander Dec 01 '17 at 20:34

7 Answers7

55

From DBCC CHECKIDENT

DBCC CHECKIDENT ( table_name, RESEED, new_reseed_value )

If no rows have been inserted to the table since it was created, or all rows have been removed by using the TRUNCATE TABLE statement, the first row inserted after you run DBCC CHECKIDENT uses new_reseed_value as the identity. Otherwise, the next row inserted uses new_reseed_value + the current increment value.

So, this is expected for an empty or truncated table.

gbn
  • 422,506
  • 82
  • 585
  • 676
  • Just FYI, the DELETE FROM statement will use the latter behavior, "the next row inserted uses new_reseed_value + the current increment value". – James McMahon Apr 27 '09 at 18:34
  • DELETE will not reset seeds.. is that what you mean? – gbn Apr 27 '09 at 18:38
  • @GBN, that is true, but what I was referring to is using DBCC CHECKIDENT (SyncSession, reseed, new_reseed_value); to reset a seed for a table after a DELETE will take the new_reseed_value and add it the current increment value for the first row. – James McMahon Apr 27 '09 at 18:55
  • 15
    This hasn't really answered the question. How do you ensure that the seed will always start at 1 - regardless of whether the table has been used or not? – Damien Sep 13 '09 at 08:41
  • 2
    @Damien: It depends on what you have done previously. You *can not* guarantee because of the quote mentioned. You have know previous actions. Or explicitly TRUNCATE or rebuild table. – gbn Sep 13 '09 at 10:21
  • 2
    this is nuts! makes no sense to me, should behavior always the same way. omg microsoft... – Ricardo Vigatti Oct 21 '16 at 12:54
  • How I did, I have a Table tcsapplicable truncate table tcsapplicable go DBCC CHECKIDENT (tcsapplicable, RESEED, 0) go id Description 0 No 1 Yes On Sales 2 Yes On Receipt 3 Yes On Other – sushil.agarwal Oct 03 '20 at 10:40
  • Saved my day, I was about to messy around searching on the net. – 4xMafole Jul 16 '21 at 12:21
8

If you pass a reseed value the DB will start the identity from that new value:

DBCC CHECKIDENT (SyncSession, RESEED, 0); --next record should be 0 + increment

You don't have to pass the a value though, if you don't IDENTITY(a,b) will be used instead:

DBCC CHECKIDENT (SyncSession, RESEED); --next record should be the seed value 'a'

This is usually better practice, as it leaves the table closer to its initial created state.

Keith
  • 150,284
  • 78
  • 298
  • 434
  • 1
    but for an empty table (or delete all rows using TRUNCATE TABLE) will make the number starts from 0 instead of 1. How to make sure the autonumber always start from 1? – Sam Dec 09 '20 at 13:48
  • @Sam two ways, either pass the new seed value with the first example, or specify it in the identity column definition. – Keith Dec 10 '20 at 19:22
  • 1
    Hi Keith, The column specified by `IDENTITY(1,1)` and I always called `DBCC CHECKIDENT (AspNetRoles, RESEED, 0);` before `INSERT` statement. However, on the very first insert (ie. the database has just been created or delete all rows using TRUNCATE TABLE), the Id always 0. – Sam Dec 13 '20 at 10:37
  • @Sam `DBCC CHECKIDENT (AspNetRoles, RESEED, 0)` will reset the identity to `0`, use `DBCC CHECKIDENT (AspNetRoles, RESEED)` to reset it to whatever the table definition states. – Keith Dec 15 '20 at 18:41
  • This doesn't work for new/truncated tables. Even Redgate Data Compare uses this double DBCC CHECKIDENT "trick" to reseed tables in generated script so I couldn't believe it just does not suffice. I've found the only working solution to be [this](https://stackoverflow.com/a/69116039/861716). – Gert Arnold Sep 11 '21 at 09:21
3

This is logical, since you've changed (reseeded) the identity value to zero ?

DBCC CHECKIDENT (SyncSession, reseed, 1)

will reseed your identity column, and make sure that the first new record will start with 1.

Frederik Gheysels
  • 56,135
  • 11
  • 101
  • 154
  • 1
    No, that's not right. The first value used if you specify 1 in this way will be 2! – David M Apr 07 '09 at 08:45
  • 1
    Ah, unless you do this on an empty table, in which case it takes the value you specify. Apologies!!! – David M Apr 07 '09 at 08:49
  • I've tried this on empty tables and now some tables start from 1 and some from 2. – Muxa Apr 07 '09 at 08:50
  • leaving the value after reseed out will use the identity(a,b) value on the table currently. This was mentioned by a lower comment but seems to work best for this situation. – howserss Oct 30 '16 at 00:39
2

I have the same problem, restoring from a backup after modifying the DB. I just add a dummy record and then delete it... then set RESEED to 0. Seems to work.

Larry
  • 21
  • 1
2

The currently accepted answer only explains this annoying phenomenon. Only one answer offers some sort of a solution, but not really practical because it requires a dummy insertion, which makes it hard to generalize.

The only generic solution is to reseed the identity value, then check the current identity value and reseed it again when it's 0. This can be done by a stored procedure:

CREATE OR ALTER PROCEDURE ReseedIdentity
    @tableName SYSNAME
AS
BEGIN
    DBCC CHECKIDENT(@tableName, RESEED, 0)
    IF IDENT_CURRENT(@tableName) = 0
    BEGIN
        DBCC CHECKIDENT(@tableName, RESEED, 1)
    END
END

This will always start new records at identity value 1, whether it's a new table, after truncating or after deleting all records.

If there are identity specifications starting at higher seed values a somewhat more advanced version can be used, which is a generalization of the former:

CREATE OR ALTER PROCEDURE ReseedIdentity
    @tableName SYSNAME
AS
BEGIN
    DECLARE @seed NUMERIC(18,0) = IDENT_SEED(@tableName) - 1;
    DBCC CHECKIDENT(@tableName, RESEED, @seed)
    IF IDENT_CURRENT(@tableName) = @seed
    BEGIN
        SET @seed = @seed + 1
        DBCC CHECKIDENT(@tableName, RESEED, @seed)
    END
END
Gert Arnold
  • 105,341
  • 31
  • 202
  • 291
1

Try this

DECLARE @c TABLE (TanvtechId varchar(10),NewTanvtechId Varchar(10))
INSERT INTO @c
SELECT TanvtechId , Row_Number() OVER (ORDER BY TanvtechId ) from Tanvtech 

UPDATE G
SET G.TanvtechId =a.NewTanvtechId 
FROM Tanvtech as G INNER JOIN @c as a ON a.TanvtechId =G.TanvtechId 
Naveed Butt
  • 2,861
  • 6
  • 32
  • 55
Tanveer
  • 11
  • 1
-1
DBCC CHECKIDENT ( Table_Name, RESEED, 0 )

This is a way to start an id with Zero(0), then delete all the rows from table and again put the data back into the table.

jotik
  • 17,044
  • 13
  • 58
  • 123
Azam
  • 1
  • 1