Le meilleur moyen d'obtenir l'identité de la ligne insérée?

Quelle est la meilleure façon d'obtenir la IDENTITYligne insérée?

Je connais @@IDENTITYet IDENT_CURRENTet SCOPE_IDENTITYmais je ne comprends pas les avantages et les inconvénients attachés à chacun.

Quelqu'un peut-il expliquer les différences et quand dois-je les utiliser?

• @@IDENTITYrenvoie la dernière valeur d'identité générée pour n'importe quelle table de la session en cours, sur toutes les étendues. Vous devez être prudent ici , car il s'agit de plusieurs étendues. Vous pouvez obtenir une valeur à partir d'un déclencheur, au lieu de votre instruction actuelle.

• SCOPE_IDENTITY()renvoie la dernière valeur d'identité générée pour n'importe quelle table de la session en cours et la portée actuelle. Généralement ce que vous souhaitez utiliser .

• IDENT_CURRENT('tableName')renvoie la dernière valeur d'identité générée pour une table spécifique dans une session et une étendue. Cela vous permet de spécifier de quelle table vous voulez que la valeur provienne, au cas où les deux ci-dessus ne seraient pas tout à fait ce dont vous avez besoin ( très rare ). En outre, comme l'a mentionné @ Guy Starbuck , "Vous pouvez l'utiliser si vous souhaitez obtenir la valeur IDENTITY actuelle pour une table dans laquelle vous n'avez pas inséré d'enregistrement."

• La OUTPUTclause de l' INSERTinstruction vous permettra d'accéder à chaque ligne insérée via cette instruction. Puisqu'il est limité à l'instruction spécifique, il est plus simple que les autres fonctions ci-dessus. Cependant, c'est un peu plus verbeux (vous devrez insérer dans une table variable / temp, puis interroger cela) et cela donne des résultats même dans un scénario d'erreur où l'instruction est annulée. Cela dit, si votre requête utilise un plan d'exécution parallèle, c'est la seule méthode garantie pour obtenir l'identité (à moins de désactiver le parallélisme). Cependant, il est exécuté avant les déclencheurs et ne peut pas être utilisé pour renvoyer des valeurs générées par les déclencheurs.

Je pense que la méthode la plus sûre et la plus précise pour récupérer l'identifiant inséré serait d'utiliser la clause de sortie.

par exemple (extrait de l' article MSDN suivant )

USE AdventureWorks2008R2;
GO
DECLARE @MyTableVar table( NewScrapReasonID smallint,
                           Name varchar(50),
                           ModifiedDate datetime);
INSERT Production.ScrapReason
    OUTPUT INSERTED.ScrapReasonID, INSERTED.Name, INSERTED.ModifiedDate
        INTO @MyTableVar
VALUES (N'Operator error', GETDATE());

--Display the result set of the table variable.
SELECT NewScrapReasonID, Name, ModifiedDate FROM @MyTableVar;
--Display the result set of the table.
SELECT ScrapReasonID, Name, ModifiedDate 
FROM Production.ScrapReason;
GO

Je dis la même chose que les autres gars, donc tout le monde a raison, j'essaie juste d'être plus clair.

@@IDENTITYrenvoie l'id de la dernière chose qui a été insérée par la connexion de votre client à la base de données.
La plupart du temps, cela fonctionne bien, mais parfois un déclencheur ira et insérera une nouvelle ligne que vous ne connaissez pas, et vous obtiendrez l'ID de cette nouvelle ligne, au lieu de celle que vous voulez

SCOPE_IDENTITY()résout ce problème. Il renvoie l'ID de la dernière chose que vous avez insérée dans le code SQL que vous avez envoyé à la base de données. Si les déclencheurs vont et créent des lignes supplémentaires, ils ne feront pas renvoyer la mauvaise valeur. Hourra

IDENT_CURRENTrenvoie le dernier ID qui a été inséré par quiconque. Si une autre application insère une autre ligne à un moment imprévu, vous obtiendrez l'ID de cette ligne au lieu de la vôtre.

Si vous voulez jouer en toute sécurité, utilisez toujours SCOPE_IDENTITY(). Si vous restez avec @@IDENTITYet que quelqu'un décide d'ajouter un déclencheur plus tard, tout votre code se cassera.

La meilleure façon (lire: la plus sûre) d'obtenir l'identité d'une ligne nouvellement insérée est d'utiliser la outputclause:

create table TableWithIdentity
           ( IdentityColumnName int identity(1, 1) not null primary key,
             ... )

-- type of this table's column must match the type of the
-- identity column of the table you'll be inserting into
declare @IdentityOutput table ( ID int )

insert TableWithIdentity
     ( ... )
output inserted.IdentityColumnName into @IdentityOutput
values
     ( ... )

select @IdentityValue = (select ID from @IdentityOutput)

Ajouter

SELECT CAST(scope_identity() AS int);

à la fin de votre instruction SQL d'insertion, puis

NewId = command.ExecuteScalar()

va le récupérer.

Lorsque vous utilisez Entity Framework, il utilise en interne la OUTPUTtechnique pour renvoyer la valeur d'ID nouvellement insérée

DECLARE @generated_keys table([Id] uniqueidentifier)

INSERT INTO TurboEncabulators(StatorSlots)
OUTPUT inserted.TurboEncabulatorID INTO @generated_keys
VALUES('Malleable logarithmic casing');

SELECT t.[TurboEncabulatorID ]
FROM @generated_keys AS g 
   JOIN dbo.TurboEncabulators AS t 
   ON g.Id = t.TurboEncabulatorID 
WHERE @@ROWCOUNT > 0

Les résultats de sortie sont stockés dans une variable de table temporaire, rejoints à la table et renvoient la valeur de ligne hors de la table.

Remarque: Je n'ai aucune idée de la raison pour laquelle EF fusionnerait intérieurement la table éphémère à la table réelle (dans quelles circonstances les deux ne correspondraient-elles pas).

Mais c'est ce que fait EF.

Cette technique ( OUTPUT) n'est disponible que sur SQL Server 2008 ou plus récent.

Modifier - La raison de la jointure

La raison pour laquelle Entity Framework rejoint la table d'origine, plutôt que d'utiliser simplement les OUTPUTvaleurs, c'est que EF utilise également cette technique pour obtenir la rowversionligne nouvellement insérée.

Vous pouvez utiliser la concurrence optimiste dans vos modèles de structure d'entité en utilisant l' Timestampattribut: ^🕗

public class TurboEncabulator
{
   public String StatorSlots)

   [Timestamp]
   public byte[] RowVersion { get; set; }
}

Lorsque vous faites cela, Entity Framework aura besoin rowversionde la ligne nouvellement insérée:

DECLARE @generated_keys table([Id] uniqueidentifier)

INSERT INTO TurboEncabulators(StatorSlots)
OUTPUT inserted.TurboEncabulatorID INTO @generated_keys
VALUES('Malleable logarithmic casing');

SELECT t.[TurboEncabulatorID], t.[RowVersion]
FROM @generated_keys AS g 
   JOIN dbo.TurboEncabulators AS t 
   ON g.Id = t.TurboEncabulatorID 
WHERE @@ROWCOUNT > 0

Et pour récupérer cela, Timetsampvous ne pouvez pas utiliser de OUTPUTclause.

C'est parce que s'il y a un déclencheur sur la table, tout TimestampSORTIE sera faux:

• Insert initial. Horodatage: 1
• La clause OUTPUT génère l'horodatage: 1
• le déclencheur modifie la ligne. Horodatage: 2

L'horodatage renvoyé ne sera jamais correct si vous avez un déclencheur sur la table. Vous devez donc utiliser un autre SELECT.

Et même si vous vouliez subir une version de ligne incorrecte, l'autre raison pour effectuer une séparation distincte SELECTest que vous ne pouvez pas SORTIR a rowversiondans une variable de table:

DECLARE @generated_keys table([Id] uniqueidentifier, [Rowversion] timestamp)

INSERT INTO TurboEncabulators(StatorSlots)
OUTPUT inserted.TurboEncabulatorID, inserted.Rowversion INTO @generated_keys
VALUES('Malleable logarithmic casing');

La troisième raison de le faire est la symétrie. Lorsque vous effectuez une opération UPDATEsur une table avec un déclencheur, vous ne pouvez pas utiliser de OUTPUTclause. Essayer de faire UPDATEavec un OUTPUTn'est pas pris en charge et donnera une erreur:

• Impossible d'utiliser UPDATE avec la clause OUTPUT lorsqu'un déclencheur est sur la table

La seule façon de le faire est avec une SELECTdéclaration de suivi :

UPDATE TurboEncabulators
SET StatorSlots = 'Lotus-O deltoid type'
WHERE ((TurboEncabulatorID = 1) AND (RowVersion = 792))

SELECT RowVersion
FROM TurboEncabulators
WHERE @@ROWCOUNT > 0 AND TurboEncabulatorID = 1

MSDN

@@ IDENTITY, SCOPE_IDENTITY et IDENT_CURRENT sont des fonctions similaires en ce sens qu'elles renvoient la dernière valeur insérée dans la colonne IDENTITY d'une table.

@@ IDENTITY et SCOPE_IDENTITY renverront la dernière valeur d'identité générée dans n'importe quelle table de la session en cours. Cependant, SCOPE_IDENTITY renvoie la valeur uniquement dans la portée actuelle; @@ IDENTITY n'est pas limité à une portée spécifique.

IDENT_CURRENT n'est pas limité par la portée et la session; il est limité à une table spécifiée. IDENT_CURRENT renvoie la valeur d'identité générée pour une table spécifique dans n'importe quelle session et n'importe quelle étendue. Pour plus d'informations, voir IDENT_CURRENT.

• IDENT_CURRENT est une fonction qui prend une table comme argument.
• @@ IDENTITY peut retourner un résultat déroutant lorsque vous avez un déclencheur sur la table
• SCOPE_IDENTITY est votre héros la plupart du temps.

@@ IDENTITY est la dernière identité insérée à l'aide de la connexion SQL actuelle. Il s'agit d'une bonne valeur à renvoyer à partir d'une procédure stockée d'insertion, où vous avez juste besoin de l'identité insérée pour votre nouvel enregistrement, et ne vous souciez pas si plus de lignes ont été ajoutées par la suite.

SCOPE_IDENTITY est la dernière identité insérée à l'aide de la connexion SQL actuelle, et dans la portée actuelle - c'est-à-dire, s'il y avait une deuxième IDENTITY insérée basée sur un déclencheur après votre insertion, elle ne serait pas reflétée dans SCOPE_IDENTITY, seulement l'insertion que vous avez effectuée . Franchement, je n'ai jamais eu de raison de l'utiliser.

IDENT_CURRENT (tablename) est la dernière identité insérée, quelle que soit la connexion ou la portée. Vous pouvez l'utiliser si vous souhaitez obtenir la valeur IDENTITY actuelle pour une table dans laquelle vous n'avez pas inséré d'enregistrement.

Je ne peux pas parler d'autres versions de SQL Server, mais en 2012, la sortie directe fonctionne très bien. Vous n'avez pas besoin de vous soucier d'une table temporaire.

INSERT INTO MyTable
OUTPUT INSERTED.ID
VALUES (...)

Soit dit en passant, cette technique fonctionne également lors de l'insertion de plusieurs lignes.

INSERT INTO MyTable
OUTPUT INSERTED.ID
VALUES
    (...),
    (...),
    (...)

Production

ID
2
3
4

Utilisez TOUJOURS scope_identity (), il n'y a JAMAIS besoin d'autre chose.

Créez un uuidet insérez-le également dans une colonne. Ensuite, vous pouvez facilement identifier votre ligne avec l'uuid. C'est la seule solution 100% fonctionnelle que vous pouvez implémenter. Toutes les autres solutions sont trop compliquées ou ne fonctionnent pas dans les mêmes cas de bord. Par exemple:

1) Créer une ligne

INSERT INTO table (uuid, name, street, zip) 
        VALUES ('2f802845-447b-4caa-8783-2086a0a8d437', 'Peter', 'Mainstreet 7', '88888');

2) Obtenez la ligne créée

SELECT * FROM table WHERE uuid='2f802845-447b-4caa-8783-2086a0a8d437';

Une autre façon de garantir l'identité des lignes que vous insérez est de spécifier les valeurs d'identité et d'utiliser le SET IDENTITY_INSERT ONpuis OFF. Cela garantit que vous savez exactement quelles sont les valeurs d'identité! Tant que les valeurs ne sont pas utilisées, vous pouvez insérer ces valeurs dans la colonne d'identité.

CREATE TABLE #foo 
  ( 
     fooid   INT IDENTITY NOT NULL, 
     fooname VARCHAR(20) 
  ) 

SELECT @@Identity            AS [@@Identity], 
       Scope_identity()      AS [SCOPE_IDENTITY()], 
       Ident_current('#Foo') AS [IDENT_CURRENT] 

SET IDENTITY_INSERT #foo ON 

INSERT INTO #foo 
            (fooid, 
             fooname) 
VALUES      (1, 
             'one'), 
            (2, 
             'Two') 

SET IDENTITY_INSERT #foo OFF 

SELECT @@Identity            AS [@@Identity], 
       Scope_identity()      AS [SCOPE_IDENTITY()], 
       Ident_current('#Foo') AS [IDENT_CURRENT] 

INSERT INTO #foo 
            (fooname) 
VALUES      ('Three') 

SELECT @@Identity            AS [@@Identity], 
       Scope_identity()      AS [SCOPE_IDENTITY()], 
       Ident_current('#Foo') AS [IDENT_CURRENT] 

-- YOU CAN INSERT  
SET IDENTITY_INSERT #foo ON 

INSERT INTO #foo 
            (fooid, 
             fooname) 
VALUES      (10, 
             'Ten'), 
            (11, 
             'Eleven') 

SET IDENTITY_INSERT #foo OFF 

SELECT @@Identity            AS [@@Identity], 
       Scope_identity()      AS [SCOPE_IDENTITY()], 
       Ident_current('#Foo') AS [IDENT_CURRENT] 

SELECT * 
FROM   #foo 

Cela peut être une technique très utile si vous chargez des données d'une autre source ou fusionnez des données de deux bases de données, etc.

Même s'il s'agit d'un thread plus ancien, il existe une nouvelle façon de le faire qui évite certains des pièges de la colonne IDENTITY dans les anciennes versions de SQL Server, comme les lacunes dans les valeurs d'identité après le redémarrage du serveur . Les séquences sont disponibles dans SQL Server 2016 et les versions ultérieures, la façon la plus récente consiste à créer un objet SEQUENCE à l'aide de TSQL. Cela vous permet de créer votre propre objet de séquence numérique dans SQL Server et de contrôler son incrémentation.

Voici un exemple:

CREATE SEQUENCE CountBy1  
    START WITH 1  
    INCREMENT BY 1 ;  
GO  

Ensuite, dans TSQL, vous procéderiez comme suit pour obtenir l'ID de séquence suivant:

SELECT NEXT VALUE FOR CountBy1 AS SequenceID
GO

Voici les liens vers CREATE SEQUENCE et NEXT VALUE FOR

Après votre déclaration d'insertion, vous devez l'ajouter. Et assurez-vous du nom de la table où les données sont insérées. Vous obtiendrez la ligne actuelle non où la ligne est affectée à l'instant par votre instruction d'insertion.

IDENT_CURRENT('tableName')