Į SQL serverio duomenų bazės lentelę įterpiau įrašų. Lentelėje buvo apibrėžtas pirminis raktas, o automatinio tapatybės padidinimo seka nustatyta į "Taip". Taip padaryta pirmiausia todėl, kad "SQL Azure" sistemoje kiekviena lentelė turi turėti apibrėžtą pirminį raktą ir tapatybę.
Tačiau kadangi turiu ištrinti kai kuriuos įrašus iš lentelės, tų lentelių tapatybės sėkla bus sutrikdyta, o indekso stulpelis (kuris automatiškai generuojamas su prieaugiu 1) bus sutrikdytas.
**Kaip ištrynus įrašus iš naujo nustatyti tapatybės stulpelį, kad stulpelis turėtų didėjančią skaičių seką?
Tapatybės stulpelis niekur duomenų bazėje nenaudojamas kaip svetimas raktas.
Valdymo komanda DBCC CHECKIDENT
naudojama tapatybės skaitikliui iš naujo nustatyti. Komandos sintaksė yra tokia:
DBCC CHECKIDENT (table_name [, { NORESEED | { RESEED [, new_reseed_value ]}}])
[ WITH NO_INFOMSGS ]
Pavyzdys:
DBCC CHECKIDENT ('[TestTable]', RESEED, 0);
GO
Ankstesnėse "Azure SQL Database" versijose jis nebuvo palaikomas, tačiau dabar palaikomas.
Atkreipkite dėmesį, kad new_reseed_value
argumentas yra skirtingas įvairiose SQL serverio versijose pagal dokumentaciją:
Jei lentelėje yra eilučių, į kitą eilutę įterpiama new_reseed_value reikšmė. SQL Server 2008 R2 ir ankstesnėse versijose kitai įterptai eilutei naudojama new_reseed_value + dabartinė padidinimo vertė.
Tačiau, mano manymu, ši informacija yra klaidinanti* (iš tikrųjų tiesiog neteisinga), nes pastebėtas elgesys rodo, kad bent jau "SQL Server 2012" vis dar naudoja new_reseed_value* + dabartinės inkremento vertės logiką. "Microsoft" netgi prieštarauja savo pačios C pavyzdžiu
, esančiu tame pačiame puslapyje:
C. Dabartinės tapatybės reikšmės primetimas į naują reikšmę
Toliau pateiktas pavyzdys priverčia dabartinę tapatybės vertę AddressTypeID stulpelio AddressType lentelės reikšmę 10. Kadangi lentelėje yra esamų eilučių, kitoje įterptoje eilutėje bus naudojama 11 kaip reikšmė, t. y. nauja dabartinė padidėjimo reikšmė, nustatyta stulpelio vertė plius 1.
USE AdventureWorks2012;
GO
DBCC CHECKIDENT ('Person.AddressType', RESEED, 10);
GO
Vis dėlto visa tai palieka kitokios elgsenos galimybę naujesnėse SQL serverio versijose. Manau, kad vienintelis būdas įsitikinti, kol "Microsoft" nepaaiškins dalykų savo dokumentuose, yra atlikti realius bandymus prieš naudojimą.