Zurücksetzen des Identitätsseeds nach dem Löschen von Datensätzen in SQL Server

Ich habe Datensätze in eine SQL Server-Datenbanktabelle eingefügt. Für die Tabelle wurde ein Primärschlüssel definiert und die automatische Identitätserweiterung ist auf "Ja" eingestellt. Dies geschieht hauptsächlich deshalb, weil in SQL Azure für jede Tabelle ein Primärschlüssel und eine Identität definiert werden müssen.

Da ich jedoch einige Datensätze aus der Tabelle löschen muss, wird der Identitäts-Seed für diese Tabellen gestört und die Indexspalte (die automatisch mit einem Inkrement von 1 generiert wird) wird gestört.

Wie kann ich die Identitätsspalte zurücksetzen, nachdem ich die Datensätze gelöscht habe, so dass die Spalte eine aufsteigende numerische Reihenfolge hat?

Die Identitätsspalte wird in der Datenbank nirgendwo als Fremdschlüssel verwendet.

Lösung

Der Verwaltungsbefehl DBCC CHECKIDENT wird verwendet, um den Identitätszähler zurückzusetzen. Die Befehlssyntax lautet:

DBCC CHECKIDENT (table_name [, { NORESEED | { RESEED [, new_reseed_value ]}}])
[ WITH NO_INFOMSGS ]

Beispiel:

DBCC CHECKIDENT ('[TestTable]', RESEED, 0);
GO

Es wurde in früheren Versionen von Azure SQL Database nicht unterstützt, wird aber jetzt unterstützt.


Bitte beachten Sie, dass das Argument new_reseed_value in den verschiedenen SQL Server-Versionen unterschiedlich ist gemäß der Dokumentation:

Wenn Zeilen in der Tabelle vorhanden sind, wird die nächste Zeile mit dem Wert new_reseed_value eingefügt. In der Version SQL Server 2008 R2 und früher wird für die nächste eingefügte Zeile new_reseed_value + der aktuelle Inkrementwert verwendet.

Ich finde diese Information jedoch irreführend* (eigentlich schlichtweg falsch), denn das beobachtete Verhalten deutet darauf hin, dass zumindest SQL Server 2012 immer noch die Logik new_reseed_value* + den aktuellen Inkrementwert verwendet. Microsoft widerspricht sogar mit seinem eigenen "Beispiel C", das auf derselben Seite zu finden ist:

C. Erzwingen des aktuellen Identitätswerts auf einen neuen Wert

Das folgende Beispiel erzwingt den aktuellen Identitätswert in der Spalte AddressTypeID Spalte in der AddressType Tabelle auf einen Wert von 10. Da die Tabelle bereits Zeilen enthält, wird die nächste eingefügte Zeile den Wert 11 als Wert, d. h. den neuen aktuellen Inkrementwert, der für die Spalte Spaltenwert plus 1.

USE AdventureWorks2012;  
GO  
DBCC CHECKIDENT ('Person.AddressType', RESEED, 10);  
GO

Dennoch lässt dies alles eine Option für ein anderes Verhalten bei neueren SQL Server-Versionen offen. Ich denke, der einzige Weg, um sicher zu sein, bis Microsoft die Dinge in seiner eigenen Dokumentation klarstellt, ist, vor der Verwendung tatsächliche Tests durchzuführen.

Kommentare (13)
DBCC CHECKIDENT ('TestTable', RESEED, 0)
GO

Wobei 0 der Startwert "Identität" ist

Kommentare (3)

Dies ist eine häufig gestellte Frage und die Antwort ist immer dieselbe: Tun Sie es nicht. Identitätswerte sollten als willkürlich behandelt werden, und als solche gibt es keine "richtige" Reihenfolge.

Kommentare (7)