Tabelle Temporanee e primary Key

Oggi sono stato interpellato perchè un collega non capiva un errore apparentemente strano.....

Provate ad eseguire da due connessioni differenti la seguente create table :

create table #test
(
a int,
b int 
    constraint [pk_test] primary key clustered (a,b)
)

Sicuramente una delle due darà il seguente errore:
Msg 2714, Level 16, State 4, Line 1
There is already an object named 'pk_test' in the database.
Msg 1750, Level 16, State 0, Line 1
Could not create constraint. See previous errors.


Ma come... le tabelle temporanee locali (quelle con solo un # come suffisso) non dovrebbero essere visibili solo all'interno del contesto di dove sono state create ?!?!?!?
Verissimo... se non fosse che Sql server memorizza nella sys.objects del tempDb (le #table sono create fisicamente nel tempDb) sia la nostra tabella #test sia la Pk creata, nel nostro caso [pk_test].

Eseguendo la query riportata nella figura andiamo a cercare in sys.objects del tempdb la nostra PK ed effettivamente viene trovata da entrambe le connessioni.

Evidenziato in rosso, il campo parent_object_id, contiene l'id dell'oggetto proprietario della pk, cioè la nostra tabella #test. Eseguiamo ora la seconda query della figura, vedremo che parent_object_id corrisponde
esattamente alla tabella #test creata da una delle 2 connessioni.

La seconda connessione trova già un oggetto con nome [pk_test] e solleva quindi un errore.
Quindi che possiamo fare ?
Semplicemente non utiliziamo una Primary Key, ma un Indice Unique , come mostrato qui sotto :

create table  #test
(
a int,
b int
)

create unique index IX on #test (a,b)

Questo indice unique , potrebbe essere anche creato clustered, impedisce l'inserimento di righe duplicate e consente di individuare in modo univoco ciascuna riga all'interno della tabella. Esattamente il risultato che mi sarei aspettato con l'utilizzo di una primary key.

Tutto ciò avviene perchè i Vincoli Unique, a cui appartengono le Primay Key, devono avere nomi univoci all'interno dei database mentre gli indici non hanno questa limitazione.

Ovviamente sorvolo sulle possibili considerazioni sull'utilizzo di Primary Key a campi multipli in tabelle.... :-)

Ciao!!