Identiteetin siemenen palauttaminen SQL Serverin tietueiden poistamisen jälkeen

Hallintakomentoa DBCC CHECKIDENT käytetään identiteettilaskurin nollaamiseen. Komennon syntaksi on:

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

Esimerkki:

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

Sitä ei tuettu Azure SQL Database -tietokannan aiemmissa versioissa, mutta sitä tuetaan nyt.

Huomaa, että new_reseed_value-argumentti vaihtelee SQL Server -versioissa dokumentaation mukaan:

Jos taulukossa on rivejä, seuraava rivi lisätään new_reseed_value-arvolla. SQL Server 2008 R2 -versiossa ja sitä aikaisemmissa versioissa seuraava lisätty rivi käyttää new_reseed_value + nykyistä lisäysarvoa.

Mielestäni tämä tieto on kuitenkin harhaanjohtava* (itse asiassa aivan väärä), koska havaittu käyttäytyminen osoittaa, että ainakin SQL Server 2012 käyttää edelleen new_reseed_value* + current increment value -logiikkaa. Microsoft on jopa ristiriidassa saman sivun esimerkin C kanssa:

C. Nykyisen identiteettiarvon pakottaminen uuteen arvoon.

Seuraavassa esimerkissä nykyinen identiteettiarvo pakotetaan nykyisen AddressType-taulukon AddressTypeID-sarakkeessa arvoksi 10. Koska taulukossa on olemassa olevia rivejä, seuraavalla lisätyllä rivillä käytetään arvoa 11 arvona, eli uusi nykyinen lisäysarvo, joka on määritelty sarakkeelle sarakkeen arvo plus 1.

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

Tämä kaikki jättää kuitenkin mahdollisuuden erilaiselle käyttäytymiselle uudemmissa SQL Server -versioissa. Ainoa tapa olla varma, kunnes Microsoft selventää asioita omassa dokumentaatiossaan, on tehdä todellisia testejä ennen käyttöä.

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

Jossa 0 on identity Alkuarvo

Tämä on yleinen kysymys, ja vastaus on aina sama: älä tee sitä. Identiteettiarvoja on pidettävä mielivaltaisina, eikä niiden järjestystä ole olemassa.