Primary key violation when inserting records with insert_identity and ident_current+x

Question

My problem is this: I have data in a couple of temporary tables including
relations (one table referencing records from another table by using
temporary keys).
Next, I would like to insert the data from the temp tables to my productive tables which have the same structure but their own identity keys. Hence, I need to translate the 'temporary' keys to regular identity keys in my productive tables.
This is even more difficult because the system is highly concurrent, i.e. multiple sessions may try to insert
data that way simultaneously.
So far we were running the following solution, using a combination of
identity_insert and ident_current:
create table doc(id int identity primary key, number varchar(100))
create table pos (id int identity primary key, docid int references doc(id), qty int)
create table #doc(idx int, number varchar(100))
create table #pos (docidx int, qty int)
insert #doc select 1, 'D1'
insert #doc select 2, 'D2'
insert #pos select 1, 10
insert #pos select 1, 12
insert #pos select 2, 32
insert #pos select 2, 9
declare @docids table(ID int)
set identity_insert doc on
insert doc (id,number)
output inserted.ID into @docids
select ident_current('doc')+idx,number from #doc
set identity_insert doc off
-- Since scope_identity() is not reliable, we get the inserted identity values this way:
declare @docID int = (select min(ID) from @docids)
insert pos (docid,qty) select @docID+docidx-1, qty from #pos
Since the request to ident_current() is located directly in the insert statement, we always have an implicit transaction which should be thread safe to a certain extend.
We never had a problem with this solution for years until recently when we were running in occasional primary key violations. After some reasearch it turned out, that there were concurrent sessions trying to insert records in this way.
Does anybody have an explanation for the primary key violations or an alternative solution for the problem?
Thank you
David

Answer 1

>> My problem is this: I have data in a couple of temporary tables including relations (one table referencing records [sic] from another table by using temporary keys [sic]). <<
NO, your problem is that you have no idea how RDBMS and SQL work. 
1. Rows are not anything like records; this is a basic concept.
2. Temp tables are how old magnetic tape file mimic scratch tapes. SQL programmers use CTEs, views, derived tables, etc. 
3. Keys are a subset of attributes of an entity, fundamental characteristics of them! A key cannot be temporary by definition. 
>> Next, I would like to insert the data from the temp tables to my production tables which have the same structure but their own IDENTITY keys. Hence, I need to translate the 'temporary' keys to regular IDENTITY keys in my productive tables. <<
NO, you just get worse. IDENTITY is a 1970's Sybase/UNIX dialect, based on the sequential file structure used on 16-bit mini computers back then. It counts the physical insertion attempts (not even successes!) and has nothing to with a logical data model. This
is a mag tape drive model of 1960's EDP, and not RDBMS.
>> This is even more difficult because the system is highly concurrent, i.e. multiple sessions may try to insert data that way simultaneously. <<
Gee, that is how magnetic tapes work, with queues. This is one of many reasons competent SQL programers do not use IDENTITY. 
>> So far we were running the following solution, using a combination of IDENTITY_INSERT and IDENT_CURRENT: <<
This is a kludge, not a solution. 
There is no such thing as a generic “id” in RDBMS; it has to be “<something in particular>_id” to be valid. You have no idea what the ISO-11179 rules are. Even worse, your generic “id” changes names from table to table! By magic, it starts as a “Doc”,
then becomes a “Pos” in the next table! Does it wind up as a “doc-id”? Can it become a automobile? A squid? Lady Gaga? 
This is the first principle of any data model; it is based on the Law of Identity; remember that from Freshman Logic 101? A data element has one and only one name in a model. 
And finally, you do not know the correct syntax for INSERT INTO, so you use the 1970's Sybase/UNIX dialect! The ANSI/ISO Standard uses a table consrtuctor: 
INSERT INTO Doc VALUES (1, 'D1'), (2, 'D2'); 
>> We never had a problem with this solution for years until recently when we were running in occasional PRIMARY KEY violations. After some research it turned out, that there were concurrent sessions trying to insert records [sic] in this way. <<
“No matter how far you have gone down the wrong road, turn around.” -- Turkish proverb. 
You have been mimicking a mag tape file system and have not written correct SQL. It has caught up with you in a way you can see. Throw out this garbage and do it right. 
--CELKO-- Books in Celko Series for Morgan-Kaufmann Publishing: Analytics and OLAP in SQL / Data and Databases: Concepts in Practice Data / Measurements and Standards in SQL SQL for Smarties / SQL Programming Style / SQL Puzzles and Answers / Thinking
in Sets / Trees and Hierarchies in SQL