Question

Ok, I am a bit less experienced in database topics, but consider the situation where you have a field named id in your table, and it’s Indexable/Increment-seeding.

So maybe you have rows 1-60 , so id is between 1-60, and the increment is at “61”.

Well if you delete rows 30-50, shouldn’t the increment go back down to “31”? Filling in those 30-50 ids, and then going back to 61?

My Question::: Why doesn’t MSSQL / SQL Server, do this? The missing unused ids between 30-50, are never to be used again.

Further, what if you manually inserted some rows, between id 500-600? When the increment gets to “500”, will it not give a “duplicate key” error? ???

So if you have some sort of table that is constantly changed by every user—deleting, inserting, deleting, inserting, you better hope id is bigint, because it’s going to quickly go into the 1,000,000+ area if you have enough users.

Answer 1

If you are using autoincrement fields, it is highly recommended to just let SQL Server handle the values for you. It does so in such a way as to minimize integrity conflicts.

That said, if you really want to reset the id values after a large delete, consider using TRUNCATE TABLE (which will reset the autoincrement value automatically) if you are purging the entire table, or DBCC CHECKIDENT if you need finer control over how this works.

EDIT:

This is to demonstrate the behavior of SQL Server when there is a manually-perpetrated gap in autoincrement ID values:

BEGIN TRAN

create table #t1 (id int identity, data int)

insert into #t1 (data) values (1)
insert into #t1 (data) values (2)
insert into #t1 (data) values (3)
insert into #t1 (data) values (4)

select * from #t1

dbcc checkident(#t1, reseed, 10)

insert into #t1 (data) values (5)
insert into #t1 (data) values (6)
insert into #t1 (data) values (7)
insert into #t1 (data) values (8)

select * from #t1

dbcc checkident(#t1, reseed, 5)

insert into #t1 (data) values (9)
insert into #t1 (data) values (10)
insert into #t1 (data) values (11)
insert into #t1 (data) values (12)
insert into #t1 (data) values (13)
insert into #t1 (data) values (14)
insert into #t1 (data) values (15)
insert into #t1 (data) values (16)

select * from #t1 -- this will demonstrate that SQL Server is quite happy to duplicate IDs if you have manually introduced a gap and then reset the ID to a lower value...

truncate table #t1

insert into #t1 (data) values (1)
insert into #t1 (data) values (2)
insert into #t1 (data) values (3)
insert into #t1 (data) values (4)

select * from #t1 -- this will show that TRUNCATE TABLE does (yes, really!) reset the autoincrement id value.

create table #t2 (id int identity primary key, data int)

insert into #t2 (data) values (1)
insert into #t2 (data) values (2)
insert into #t2 (data) values (3)
insert into #t2 (data) values (4)

select * from #t2

dbcc checkident(#t2, reseed, 10)

insert into #t2 (data) values (5)
insert into #t2 (data) values (6)
insert into #t2 (data) values (7)
insert into #t2 (data) values (8)

select * from #t2

dbcc checkident(#t2, reseed, 5)

-- the errors you are about to get should demonstrate that if there is an integrity constraint (in this case, the ever-popular PRIMARY KEY constraint) you will get errors when attempting to insert duplicates.

insert into #t2 (data) values (9)
insert into #t2 (data) values (10)
insert into #t2 (data) values (11)
insert into #t2 (data) values (12)
insert into #t2 (data) values (13)
insert into #t2 (data) values (14)
insert into #t2 (data) values (15)
insert into #t2 (data) values (16)

select * from #t2

ROLLBACK