Benutzer mit den meisten Antworten
Getting the current Identity value

Frage
-
Hi,
When one reseeds a table with the following statement, is it possible to find out what was the last value that has been incremented
DBCC CHECKIDENT ('TABLE_NAME', reseed,10)
If one try with other statment like IDENT_CURRENT('TABLE_NAME') there is a chance that the value that has been actually reseeded is different from the one which is given by the IDENT_CURRENT when parallel multiple transactions are running. Have any Idea how to actually find the value that has been updated?
Antworten
-
Hallo,
wie gestern auch im anderen Thread geschrieben, sind Identity Attribute dafür nicht geschaffen worden.
Entweder man akzeptiert die Werte so wie sie sind, oder man handelt sich nur Probleme ein.Wenn Du mit Bulk Load arbeiten willst, so müsstest Du die Werte vorher festlegen
und könntest sie dann mit KEEPIDENTITY übernehmen.Da Du nichts über das Ausgangsformat der Daten gesagt hast, kann ich dazu kaum mehr sagen.
Eine Alternative wäre ein Uniqueidentifier, den man unabhängig erzeugen kann.
Mit NEWSEQUENTIALID könnte man dabei die Fragmentierung der Tabellen vermeiden,
die ansonsten bei größeren Mengen Problemen bereitet.Oder eben wie im anderen Thread erwähnt eigene Nummernkreise erzeugen.
Gruß Elmar
- Als Antwort vorgeschlagen Uwe RickenMVP Dienstag, 31. Januar 2012 14:44
- Als Antwort markiert Robert BreitenhoferModerator Donnerstag, 9. Februar 2012 10:56
Alle Antworten
-
Hallo,
Identätswerte werden erst in dem Moment erzeugt, wenn die Zeile in die Tabelle eingefügt wird.
Den vergebenen Identitätswert kannst Du neben SCOPE_IDENTITY auch über die OUTPUT Klausel ermitteln,
was geeigneter ist, wenn mehrere Zeilen eingefügt werden.IDENT_CURRENT kann kein zuverlässiges Ergebnis liefern, da sich der Wert zwischen dem Abruf
und dem Einfügen bereits verändert haben kann, siehe auch Dokumentation:IDENT_CURRENT ist nur bedingt geeignet, um den nächsten generierten Identitätswert vorherzusagen.
Der tatsächlich generierte Wert kann sich aufgrund von Einfügungen durch andere Sitzungen von
IDENT_CURRENT plus IDENT_INCR unterscheiden.Gruß Elmar
-
Hallo,
Danke für die Rückmeldung.
„IDENT_CURRENT kann kein zuverlässiges Ergebnis liefern“ - genau das ist mein Problem. Aber kann SCOPE_ENTITY in Multi-Transaktionen Umfeld immer eindeutige ID liefern?
Mit der OUTPUT Klausel kannst Du in dem Fall ein Beispiel geben. Danke
-
Hallo,
SCOPE_IDENTITY() liefert den letzten IDENTITY Wert im aktuellen Bereich der aktuellen Sitzung.
Zur OUTPUT-Klausel:
CREATE TABLE dbo.Tabelle ( Id int IDENTITY(1, 1) NOT NULL PRIMARY KEY, Datum datetime2 NOT NULL); GO -- Direkte Ausgabe (an Client) INSERT INTO dbo.Tabelle (Datum) OUTPUT inserted.Id SELECT TOP(10) GETUTCDATE() FROM sys.columns; GO -- In Tabellenvariable DECLARE @InsertedTabelle TABLE ( Id int NOT NULL, Datum datetime2 NOT NULL); INSERT INTO dbo.Tabelle (Datum) OUTPUT inserted.Id, inserted.Datum INTO @InsertedTabelle SELECT TOP(10) GETUTCDATE() FROM sys.columns; SELECT * FROM @InsertedTabelle; GO DROP TABLE dbo.Tabelle;
Gruß Elmar -
Vielen Dank für das Beispiel. Ich erkläre mal mein Problem:
Es soll groß Menge Daten in einer Tabelle gespeichert werden. Dazu möchte ich gerne Bulk nutzen. Da die einzelne Insert macht es den Vorgang langsamer. Ich nehme den aktuell Identity und Reseed es mit benötigen Anzahl der Einträge. Somit habe ich zum Beispiel nächten 1000 Ids reserviert. Ich brauche diese ID um die Daten in den Untertabellen zu speichern. Hier habe ich bedenken, dass zwischen lesen der aktuelle ID und Reseed kann ein andere Transaktion eimischen.
Hast Du zu dem Problem vielleicht ein besser Lösung ?
Danke & Gruß
-
Hallo,
wie gestern auch im anderen Thread geschrieben, sind Identity Attribute dafür nicht geschaffen worden.
Entweder man akzeptiert die Werte so wie sie sind, oder man handelt sich nur Probleme ein.Wenn Du mit Bulk Load arbeiten willst, so müsstest Du die Werte vorher festlegen
und könntest sie dann mit KEEPIDENTITY übernehmen.Da Du nichts über das Ausgangsformat der Daten gesagt hast, kann ich dazu kaum mehr sagen.
Eine Alternative wäre ein Uniqueidentifier, den man unabhängig erzeugen kann.
Mit NEWSEQUENTIALID könnte man dabei die Fragmentierung der Tabellen vermeiden,
die ansonsten bei größeren Mengen Problemen bereitet.Oder eben wie im anderen Thread erwähnt eigene Nummernkreise erzeugen.
Gruß Elmar
- Als Antwort vorgeschlagen Uwe RickenMVP Dienstag, 31. Januar 2012 14:44
- Als Antwort markiert Robert BreitenhoferModerator Donnerstag, 9. Februar 2012 10:56
-
Hallo Systemtechnik,
Ich gehe davon aus, dass die Antwort Dir weitergeholfen hat.
Solltest Du noch "Rückfragen" dazu haben, so gib uns bitte Bescheid.Grüße,
Robert
Robert Breitenhofer, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.