none
Getting the current Identity value RRS feed

  • 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?

    Montag, 30. Januar 2012 14:02

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

    Dienstag, 31. Januar 2012 08:56
    Beantworter

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

    Montag, 30. Januar 2012 15:29
    Beantworter
  • 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

    Montag, 30. Januar 2012 16:00
  • 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

    Montag, 30. Januar 2012 16:55
    Beantworter
  • 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ß

    Montag, 30. Januar 2012 20:37
  • 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

    Dienstag, 31. Januar 2012 08:56
    Beantworter
  • 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  Twitter Facebook
    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.

    Donnerstag, 9. Februar 2012 10:56
    Moderator