Identitātes sēklu atiestatīšana pēc ierakstu dzēšanas SQL Serverī

Identitātes skaitītāja atiestatīšanai izmanto DBCC CHECKIDENT vadības komandu. Komandas sintakse ir šāda:

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

Piemērs:

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

Iepriekšējās Azure SQL datubāzes versijās tas nebija atbalstīts, bet tagad tiek atbalstīts.

Lūdzu, ņemiet vērā, ka new_reseed_value arguments atšķiras dažādās SQL Server versijās saskaņā ar dokumentāciju:

Ja tabulā ir rindas, nākamā rinda tiek ievietota ar new_reseed_value vērtību. SQL Server 2008 R2 un agrākajās versijās nākamajā ievietotajā rindā tiek izmantota new_reseed_value + pašreizējā pieauguma vērtība.

Tomēr es uzskatu, ka šī informācija ir maldinoša* (patiesībā vienkārši nepareiza), jo novērotā uzvedība liecina, ka vismaz SQL Server 2012 joprojām izmanto new_reseed_value* + pašreizējā pieauguma vērtības loģiku. Microsoft pat ir pretrunā ar savu pašu C piemēru, kas atrodams tajā pašā lapā:

C. Pašreizējās identitātes vērtības piespiešana jaunajai vērtībai

Šajā piemērā pašreizējā identitātes vērtība tiek piespiesta AddressTypeID slejā AddressType tabulā uz vērtību 10. Tā kā tabulā ir esošas rindas, nākamajā ievietotajā rindā tiks izmantota 11 kā vērtību, t. i., jauno pašreizējo pieauguma vērtību, kas noteikta tabulai slejas vērtība plus 1.

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

Tomēr tas viss atstāj iespēju jaunākajās SQL Server versijās rīkoties citādi. Domāju, ka vienīgais veids, kā būt pārliecinātam, kamēr Microsoft savā dokumentācijā neskaidros lietas, ir veikt faktiskus testus pirms lietošanas.

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

Kur 0 ir identitātes sākuma vērtība

Šis ir bieži uzdots jautājums, un atbilde vienmēr ir viena un tā pati: nedariet to. Identitātes vērtības jāuzskata par patvaļīgām, un tāpēc nav "pareizas kārtības".