SQL Server identity column and imports - sql-server

Question

I'll try and explain in simple terms leaving out the whys and wheres of how this occured.
Currently there are 2 databases that need to be merged, they have the same tables etc and in some cases lookup tables are identical, in some cases they are and in some cases records in one database have different identity values for there equivalent in the other DB. So it's a mess.
Let us say on one of the databases we update all the identity values bu adding 10,000 to them and updating the related records. Then we could import the data as is and yes in some cases lookups would have the same value twice with different identities.
The question will not be regarding the above mess :). I want to know after re enabling the identity column we will have seed values of
1,2,3,4,5 etc and 10001, 10002, 10003 etc. Should more rows be inserted and they continue from lets just say 9999 will the identity column use 10,000 and then 10,004 or will SQL Server complain on the next insert that the identity value is already used?

Answer 1

I just tested this with simple INSERT's: you have to disable IDENTITY_INSERT first for each table you want to import data
SET IDENTITY_INSERT table OFF
Then you can insert your data with their original identity column values (which you'll need in order to maintain the references correctly)
After
SET IDENTITY_INSERT table ON
SQL Server continues the sequence with the highest element plus one, so in your case (after inserting IDs 10001, 10002, 10003) it would continue with 10004.

Answer 2

It's important to realise that, although they frequently appear together, IDENTITY and PRIMARY KEY are two orthogonal concepts1. So, to the question as asked, the answer is no - as IDENTITY column will quite happily provide a value that has already been used in the same column:
set nocount on
go
create table II (
ID int IDENTITY(1,1) not null,
Value varchar(10) not null
)
insert into II(Value) values ('abc'),('def')
set identity_insert II on
insert into II(ID,Value) values (6,'ghi')
set identity_insert II off
select * from II
insert into II(Value) values ('jkl')
select * from II
GO
dbcc checkident (II, RESEED, 5);
GO
insert into II(Value) values ('mno'),('pqr')
select * from II
Results:
ID Value
----------- ----------
1 abc
2 def
6 ghi
ID Value
----------- ----------
1 abc
2 def
6 ghi
7 jkl
Checking identity information: current identity value '7'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
ID Value
----------- ----------
1 abc
2 def
6 ghi
7 jkl
6 mno
7 pqr
Whereas a PRIMARY KEY will complain if you attempt to insert a duplicate value:
create table III (
ID int IDENTITY(1,1) not null PRIMARY KEY,
Value varchar(10) not null
)
insert into III(Value) values ('abc'),('def')
set identity_insert III on
insert into III(ID,Value) values (6,'ghi')
set identity_insert III off
select * from III
insert into III(Value) values ('jkl')
select * from III
GO
dbcc checkident (III, RESEED, 5);
GO
insert into III(Value) values ('mno'),('pqr')
select * from III
go
(The only different from the previous script is the table name and the addition of PRIMARY KEY)
Results:
ID Value
----------- ----------
1 abc
2 def
6 ghi
ID Value
----------- ----------
1 abc
2 def
6 ghi
7 jkl
Checking identity information: current identity value '7'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Msg 2627, Level 14, State 1, Line 1
Violation of PRIMARY KEY constraint 'PK__III__3214EC27FCCBBCB7'. Cannot insert duplicate key in object 'dbo.III'. The duplicate key value is (6).
The statement has been terminated.
ID Value
----------- ----------
1 abc
2 def
6 ghi
7 jkl
1 The third concept that is frequently conflated with these two is that of the Clustered Index. It's perfectly possible for a table to have a Primary Key, an Identity Column and a Clustered Index that have no columns in common.