SQL Server Identity column does not behave properly? - sql

Question

I created a table named tblEmployees with code -
Create table tblEmployees
(
EmployeeID int identity primary key,
Name nvarchar(30),
Salary float,
Gender tinyint
)
Then I inserted values-
insert into tblEmployees values ('Akmal', 5000, 0)
insert into tblEmployees values ('Shakira', 6000, 1)
insert into tblEmployees values ('Kiron', 7000, 2)
insert into tblEmployees values ('Jamil', 5500, 0)
insert into tblEmployees values ('Faul', 4800, 4)
But, when the values are shown -
EmployeeID Name Salary Gender
2 Akmal 5000 0
3 Shakira 6000 1
4 Kiron 7000 2
5 Jamil 5500 0
7 Faul 4800 4
My question is, why EmployeeID column started with 2? And where is 6? Shouldnt this be incremented automatically?

Answer 1

Do not rely on IDENTITY columns to produce a contiguous set of values with no gaps. Period. This is not guaranteed at all; several things can cause gaps such as rollbacks, deletes, reseeds, etc. I don't believe you reproduced this problem with that exact code above; there was probably other activity in between those INSERT statements.
For such surrogate and meaningless values you really shouldn't care if there are gaps or not. If you care about gaps, use a different technique (e.g. a serializable max()+1 solution) - just be aware that you trade gaps for scalability / concurrency concerns. The other answer (which you accepted, but I suspect will get deleted) said:
If you want to have an identity column with dependable and specified values then you need to set IDENTITY_INSERT to ON on that column, insert your values (with specific ID values) and then set IDENTITY_INSERT to OFF.
This only works if you already know the values you want to insert into that column. Which defeats the purpose of the IDENTITY property in the first place. If you don't already know what values to insert (e.g. what is the "next" ID), it means you need to SELECT MAX() from the table, and add 1 to it. Which means the whole thing needs to be serializable, otherwise someone else can read your same MAX() value and add the same +1 to it. So aside from making the IDENTITY property useless if you're always going to override the generated value anyway, it also kills scalability by effectively limiting concurrency to 1. I highly recommend you strongly weigh that approach before implementing it.
What I suggest you do instead, is use an IDENTITY column, and don't be hung up on gaps. They're going to happen, there's not much you can do about it, and it shouldn't really be a concern anyway. Who cares if there is no employee #6?

Answer 2

Your T-SQL script is incomplete because my IDENTITY values are generated starting with 1 (and ending with 5).
Note #0: I'm only try to describe some reasons for those missing IDENTITY values.
Note #1: Don't run this script on a production server.
Note #2: Using IDENTITY within a column definition means IDENTITY(1,1) <=> IDENTITY(seed value/initial value=1,increment value=1).
Note #3: You should avoid using DBCC CHECKIDENT if you aren't aware about the consequences of this command.
The first missing value (a possible explanation):
why EmployeeID column started with 2?
Run the following script:
IF OBJECT_ID(N'dbo.tblEmployees') IS NOT NULL
DROP TABLE dbo.tblEmployees;
GO
Create table tblEmployees
(
EmployeeID int identity primary key,
Name nvarchar(30),
Salary float,
Gender tinyint
)
GO
insert into tblEmployees values ('Akmal', 5000, 0)
insert into tblEmployees values ('Shakira', 6000, 1)
insert into tblEmployees values ('Kiron', 7000, 2)
insert into tblEmployees values ('Jamil', 5500, 0)
insert into tblEmployees values ('Faul', 4800, 4)
GO
SELECT SCOPE_IDENTITY() AS [Last IDENTITY #1];
/*
Last IDENTITY #1
----------------
5
*/
GO
At this moment the last IDENTITY value generated for this table is (as you can see) 5 and not 7 (like your example).
SELECT * FROM dbo.tblEmployees;
/*
EmployeeID Name Salary G
----------- ------------------------------ ---------------------- -
1 Akmal 5000 0
2 Shakira 6000 1
3 Kiron 7000 2
4 Jamil 5500 0
5 Faul 4800 4
*/
GO
All rows have continuous IDENTITY values: there are no gaps.
Now, for some reasons, somebody deletes all rows from dbo.tblEmployees and also decides to reset (RESEED) the last identity value (which is 5) to 1 (from 5 to 1).
DELETE dbo.tblEmployees;
GO
DBCC CHECKIDENT('dbo.tblEmployees', RESEED, 1);
GO
SELECT SCOPE_IDENTITY() AS [Last IDENTITY #2];
/*
Last IDENTITY #2
----------------
1
*/
GO
Now, the last IDENTITY value is 1 (because of that RESEED 1).
insert into tblEmployees values ('Akmal', 5000, 0)
insert into tblEmployees values ('Shakira', 6000, 1)
insert into tblEmployees values ('Kiron', 7000, 2)
insert into tblEmployees values ('Jamil', 5500, 0)
insert into tblEmployees values ('Faul', 4800, 4)
GO
SELECT * FROM dbo.tblEmployees;
GO
/*
EmployeeID Name Salary Gender
----------- ------------------------------ ---------------------- ------
2 Akmal 5000 0
3 Shakira 6000 1
4 Kiron 7000 2
5 Jamil 5500 0
6 Faul 4800 4
*/
When I insert those rows again, the first generated IDENTITY value is 2 (this time).
Why ? The reason is described in MSDN:
"If no rows have been inserted into the table since the table was created, or if 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."
This last formula explains why this time the first IDENTITY value is 2:
new_reseed_value (is 1 - because of RESEED 1) + the current increment value (1 - see Note #2) = 1 + 1 = 2.
Note #4: If you are using TRUNCATE TABLE instead of DELETE then the first row inserted after TRUNCATE TABLE will have the ID = seed value (see Note #2) or new_reseed_value = 1. So, in this case you don't need DBCC(..., RESEED, 1).
The second missing value (a possible explanation):
And where is 6?
DELETE dbo.tblEmployees WHERE EmployeeID = 6
insert into tblEmployees values ('Faul', 4800, 4)
GO
SELECT SCOPE_IDENTITY() AS [Last IDENTITY #3];
/*
Last IDENTITY #3
----------------
7
*/
GO
SELECT * FROM dbo.tblEmployees;
GO
/*
EmployeeID Name Salary Gender
----------- ------------------------------ ---------------------- ------
2 Akmal 5000 0
3 Shakira 6000 1
4 Kiron 7000 2
5 Jamil 5500 0
7 Faul 4800 4
*/

Answer 3

Not sure why my previous answer was voted down and deleted or blocked, but if you want to have an identity column with dependable and specified values then you need to set IDENTITY_INSERT to ON on that column, insert your values (with specific ID values) and then set IDENTITY_INSERT back to OFF.
If you do not care what the values end up being (which is probably the case with an Employees table), then forget about it and learn to live with whatever these values end up being.