Beides sind Funktionen, um den Wert der Identity-Column nach dem Insert zu erhalten. Als ich SQL Server gelernt hatte (1997), hatte ich nur @@identity gekannt.<\/p>\n
@@Identity hat aber einen entscheidenden Nachteil, aber dazu sp\u00e4ter mehr.<\/p>\n
Nehmen wir an, wir haben eine Kunden-Tabelle mit Identity-Column KundeID:<\/p>\n
\nCREATE TABLE [dbo].[Kunden](
[KundeID] [int] IDENTITY(1,1) NOT NULL,
[Name] [nvarchar](50) NOT NULL,
CONSTRAINT [PK_Kunden] PRIMARY KEY CLUSTERED
(
[KundeID] ASC
)
)<\/p>\n<\/blockquote>\nWenn wir in diese Tabelle einen Kunden eintragen und dann das Ergebnis mit @@Identity oder SCOPE_Identity() abfragen, gibt es keinen Unterschied:<\/p>\n
\nINSERT INTO Kunden SELECT ‚Martin‘
SELECT @@IDENTITY
SELECT SCOPE_Identity()<\/p>\n<\/blockquote>\nBeides liefert den Wert 1.<\/p>\n
Wenn wir aber nun eine Logging-Tabelle hinzuf\u00fcgen, die ebenfalls eine Identity-Column hat:<\/p>\n
\nCREATE TABLE [dbo].[Logging](
[LogID] [int] IDENTITY(1,1) NOT NULL,
[Timestamp] [datetime] NOT NULL default(getdate()),
[Logtext] [nvarchar](max) NULL,
CONSTRAINT [PK_Logging] PRIMARY KEY CLUSTERED
(
[LogID] ASC
)
)<\/p>\n<\/blockquote>\nUnd der Tabelle Kunden einen Insert-Trigger geben, der in diese Tabelle schreibt:<\/p>\n
\nCREATE TRIGGER dbo.tr_i_Kunden
ON dbo.Kunden
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
INSERT INTO Logging (LogText) VALUES (‚Kunde angelegt‘)
INSERT INTO Logging (LogText) VALUES (‚und dann habe ich noch \u00fcberpr\u00fcft, ob er schon da ist‘)
INSERT INTO Logging (LogText) VALUES (‚und noch irgendwas anderes auch gemacht‘)<\/p>\nEND<\/p>\n<\/blockquote>\n
Wenn wir jetzt einen Kunden anlegen, werden automatisch noch 3 Zeilen in die Logging-Tabelle geschrieben. <\/p>\n
Da @@identity<\/strong> die letzte <\/strong>Identity-Column der aktuellen Connection<\/strong> zur\u00fcckliefert, liefert dies den Identity-Wert aus der Logging-Tabelle.<\/p>\n
Da SCOPE_Identity()<\/strong> die letzte<\/strong> Identity-Column des aktuellen Scopes<\/strong> (also der betrachteten Tabelle) in der aktuellen Connection<\/strong> zur\u00fcckliefert, gibt das den Identity-Wert der Kunden-Tabelle.<\/p>\n
Wir sehen das hier:<\/p>\n
\nINSERT INTO Kunden SELECT ‚mein Schatz‘
SELECT @@IDENTITY
SELECT SCOPE_Identity()<\/p>\n<\/blockquote>\nliefert die Werte 3 f\u00fcr @@identity (da in Logging als letztes die Zeile 3 eingef\u00fcgt wurde) bzw. 2 f\u00fcr Scope_identity().<\/p>\n
Man sollte deshalb grunds\u00e4tzlich SCOPE_IDENTITY() verwenden, da dies das in der Regel gew\u00fcnschte Verhalten ist.<\/p>\n
Es gibt noch eine Funktion IDENT_CURRENT(\u2018Tabellenname\u2019). Diese liefert den letzten Identity-Wert f\u00fcr diese Tabelle \u2013 egal ob aus meiner Connection oder nicht. Damit sollte man also nicht versuchen, den gerade eingef\u00fcgten Identity-Wert zu ermitteln. Wenn n\u00e4mlich parallel eine andere Connection schreibt, hat man Pech gehabt.<\/p>\n","protected":false},"excerpt":{"rendered":"
Beides sind Funktionen, um den Wert der Identity-Column nach dem Insert zu erhalten. Als ich SQL Server gelernt hatte (1997), hatte ich nur @@identity gekannt. @@Identity hat aber einen entscheidenden Nachteil, aber dazu sp\u00e4ter mehr. Nehmen wir an, wir haben eine Kunden-Tabelle mit Identity-Column KundeID: CREATE TABLE [dbo].[Kunden]( [KundeID] [int] IDENTITY(1,1) NOT NULL, … Scope_Identity statt @@Identity<\/span> weiterlesen