Question

I have various reasons for needing to implement, in addition to the identity column PK, a second, concurrency safe, auto-incrementing column in a SQL Server 2005 database. Being able to have more than one identity column would be ideal, but I’m looking at using a trigger to simulate this as close as possible to the metal.

I believe I have to use a serializable isolation level transaction in the trigger. Do I go about this like Ii would use such a transaction in a normal SQL query?

It is a non-negotiable requirement that the business meaning of the second incrementing column remain separated from the behind the scenes meaning of the first, PK, incrementing column.

To put things as simply as I can, if I create JobCards ‘0001’, ‘0002’, and ‘0003’, then delete JobCards ‘0002’ and ‘0003’, the next Jobcard I create must have ID ‘0002’, not ‘0004’.

Answer 1

This is probably a terrible idea, but it works in at least a limited use scenario

Just use a regular identity and reseed on deletes.

create table reseedtest (
   a int identity(1,1) not null,
   name varchar(100)
)

insert reseedtest values('erik'),('john'),('selina')
select * from reseedtest

go
CREATE TRIGGER TR_reseedtest_D ON reseedtest FOR DELETE
AS
BEGIN TRAN
DECLARE @a int
SET @a = (SELECT TOP 1 a FROM reseedtest WITH (TABLOCKX, HOLDLOCK))
--anyone know another way to lock a table besides doing something to it?
DBCC CHECKIDENT(reseedtest, reseed, 0)
DBCC CHECKIDENT(reseedtest, reseed)
COMMIT TRAN
GO

delete reseedtest where a >= 2
insert reseedtest values('katarina'),('david')
select * from reseedtest

drop table reseedtest

This won’t work if you are deleting from the “middle of the stack” as it were, but it works fine for deletes from the incrementing end.

Reseeding once to 0 then again is just a trick to avoid having to calculate the correct reseed value.