Bei Autoinkrement die ID zurückbekommen

[alexdgg]

Hallo Leute,

Ich arbeite mit SQL-Server2005 und dem jtds 1.21 Treiber für Java. Wenn ich einen neuen Datensatz in der DB anlege, der bei der ID Spalte ein Autoinkrement hat, weis ich nicht wie ich nach dem Anlegen des Datensatzes den Wert für die ID zurückbekomme. Im u.g. Beispiel gibt System.out.println(qry.getInt("ID")); immer den Wert 1 zurück.

qry.open();
qry.insertRow(true);
qry.saveChanges();
qry.refresh();
System.out.println(qry.getInt("ID"));
qry.close();

[Bruno Eberle]

Hallo,

ich kenne mich leider mit dem Java-Treiber nicht aus, aber die durch den Aufruf eingefügte Identity ist danach in der System-Variablen @@IDENTITY des SQL-Servers gespeichert und im Kontext des Aufrufs gültig.
In einer Stored Procedure würde man den Wert auslesen und z.B. als Output-Parameter zurückgeben.

Gruß, Bruno

[O. Helper]

Hallo Alexdgg, hallo Bruno,

besser nicht @@IDENTITY verwenden, den siehe BOL:
"Eine Systemfunktion, die den zuletzt eingefügten Identitätswert zurückgibt."
will heissen, es liefert die von irgendeinen eingefügte Identity, nicht die von Dir.

Besser SCOPE_IDENTITY oder IDENT_CURRENT verwenden:
[highlight=SQL]create table #dummy(myid int identity(1,1));
GO
insert into #dummy default values;
GO
SELECT @@IDENTITY, SCOPE_IDENTITY(), IDENT_CURRENT('#dummy')
GO
DROP TABLE #dummy
[/highlight]

[Bruno Eberle]

Hallo Olaf,

mein SQL Server 2005 Entwicklerbuch sagt

@@IDENTITY: Diese globale Variable liefert den letzten Identity-Wert zurück, der in der Benutzerverbindung generiert wurde ... @@IDENTITY liefert garantiert keine Werte, die von parallelen Transaktionen anderer Benutzerverbindungen eingefügt wurden.

Mir kommt das auch seltsam vor, da es ja angeblich eine globale System-Variable ist.
Im Buch wird allerdings auch die Verwendung von SCOPE_IDENTITY() empfohlen, aber nur weil @@IDENTITY eventuell durch mittels Trigger gestartete Folgeaktionen nach dem INSERT überschrieben werden könnte. SCOPE_IDENTITY() beschränkt den Gültigkeitsbereich auf jeden Fall auf die ausgeführte Prozedur, Batch, etc.
Du hast also auf jeden Fall recht, dass SCOPE_IDENTITY die bessere Wahl ist.
Aber ist die @@IDENTITY Info im Buch falsch?

Gruß, Bruno

[O. Helper]

Die Frage kannst Du ganz leicht selbst beantworten: Mach eine global-Temporäre Tabelle raus
[highlight=SQL]CREATE TABLE ##dummy(myid int identity(1,1));
GO
INSERT INTO ##dummy default values;
GO
SELECT @@IDENTITY, SCOPE_IDENTITY(), IDENT_CURRENT('##dummy')
GO
--Für später
--DROP TABLE ##dummy [/highlight]
Führe es aus, öffne eine zweite Abfrage und führe das aus:
SELECT @@IDENTITY, SCOPE_IDENTITY(), IDENT_CURRENT('##dummy')

Bei mir kommt folgendes raus:
1. Abfrage (mit dem CREATE)
1/1/1

2. Abfrage
70423/NULL/1

Die ID kommt bei mir vom Logon-Trigger, der den Vorgang wegschreibt.
Wechsel dann mal die DB und führe wieder Abfrage 2 aus: Gleiche Ergebnis.
D.h. @@IDENTITY liefert wirklich eine zuletzt einfügte Identity, wenn den eine eingefügt wurde.
Mach nun mal folgendes
[highlight=SQL]CREATE TABLE ##Dummy2 (dt datetime DEFAULT GetDate());
GO
INSERT INTO ##Dummy2 DEFAULT VALUES;
GO
SELECT @@IDENTITY, SCOPE_IDENTITY(), IDENT_CURRENT('##dummy')
[/highlight]
Ergebnis:
NULL/NULL/1
Und warum? Weil bei der letzten Einfügung kein Identity betroffen war, gibt es NULL.

[alexdgg]

Danke hat mir sehr geholfen!