views:

1908

answers:

3

Hi, 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 sill start from 0 and some from 1.

Any pointers?

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

+1  A: 

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
No, that's not right. The first value used if you specify 1 in this way will be 2!
David M
Ah, unless you do this on an empty table, in which case it takes the value you specify. Apologies!!!
David M
I've tried this on empty tables and now some tables start from 1 and some from 2.
Muxa
As expected. The DBCC has different behaviours.. this is a misleading answer...
gbn
+5  A: 

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
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
DELETE will not reset seeds.. is that what you mean?
gbn
@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
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
@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
A: 

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