Malgré sa présence dans de nombreux scripts, la valeur système @@IDENTITY est à mon sens à proscrire. Je vais chercher à démontrer dans ce petit papier pourquoi et par quoi la remplacer.

En reprenant l’aide en ligne, il est indiqué que @@IDENTITY retourne « la dernière valeur d’identité insérée. ». Jusqu’ici, tout semble normal.

Mais en y regardant de plus prêt, et surtout en lisant entre les lignes, on peut trouver certaines cas dans lesquels ont n’a pas tout à fait ce à quoi on pourrait s’attendre.

Par exemple, considérons le cas d’insertion dans une table avec un déclencheur. L’aide en ligne nous indique clairement que, si le déclencheur lui-même fait des insertions, ce sont ces dernières qui risquent d’être prises en compte.

CREATE TABLE TableAvecTrigger(Id int IDENTITY, Valeur varchar(max))
GO
CREATE TABLE TableTrace(Id int IDENTITY, Texte varchar(max))
GO
CREATE TRIGGER TR_Test ON TableAvecTrigger FOR INSERT
AS
BEGIN
	SET NOCOUNT ON
	insert into TableTrace (Texte) values ('Début Trace');
	insert into TableTrace (Texte) select 'Insertion de ' + Valeur from inserted
	insert into TableTrace (Texte) values ('Fin Trace');
END
GO

A ce moment-là, les valeurs retournées par @@IDENTITY ne correspondent pas du tout aux valeurs des instructions INSERT principales …

On voit ici que les valeurs des derniers identifiants techniques retournés ne correspondent pas à la table que l’on est en train de remplir, mais sont en fait biaisés du fait de l’action du déclencheur, qui impacte lui aussi une table avec une colonne IDENTITY.

La solution à ce problème se nomme SCOPE_IDENTITY. Cette instruction permet de retourner la dernière valeur d’IDENTITY insérée, mais en se limitant à l’étendue courante. De fait, l’action du déclencheur, qui est dans une autre étendue, n’a pas d’impact.

En conclusion, évitez absolument le @@IDENTITY, et remplacez-le systématiquement par SCOPE_IDENTITY(), à moins bien entendu que vous cherchiez vraiment à obtenir des résultats « spéciaux » …