La DBCC CHECKIDENT
commande de gestion est utilisée pour réinitialiser le compteur d'identité. La syntaxe de la commande est:
DBCC CHECKIDENT (table_name [, { NORESEED | { RESEED [, new_reseed_value ]}}])
[ WITH NO_INFOMSGS ]
Exemple:
DBCC CHECKIDENT ('[TestTable]', RESEED, 0);
GO
Il n'était pas pris en charge dans les versions précédentes d'Azure SQL Database, mais il est désormais pris en charge.
Veuillez noter que l' new_reseed_value
argument varie selon les versions de SQL Server selon la documentation :
Si des lignes sont présentes dans le tableau, la ligne suivante est insérée avec la valeur new_reseed_value . Dans la version SQL Server 2008 R2 et versions antérieures, la ligne suivante insérée utilise new_reseed_value + la valeur d'incrément actuelle.
Cependant, je trouve ces informations trompeuses (tout simplement fausses en fait) car le comportement observé indique qu'au moins SQL Server 2012 utilise toujours new_reseed_value + la logique de valeur d'incrément actuelle. Microsoft contredit même son propre Example C
contenu sur la même page:
C. Forcer la valeur d'identité actuelle à une nouvelle valeur
L'exemple suivant force la valeur d'identité actuelle dans la colonne AddressTypeID de la table AddressType à une valeur de 10. Étant donné que la table contient des lignes existantes, la ligne suivante insérée utilisera 11 comme valeur, c'est-à-dire la nouvelle valeur d'incrément actuelle définie pour la valeur de la colonne plus 1.
USE AdventureWorks2012;
GO
DBCC CHECKIDENT ('Person.AddressType', RESEED, 10);
GO
Pourtant, tout cela laisse une option pour un comportement différent sur les nouvelles versions de SQL Server. Je suppose que la seule façon d'être sûr, jusqu'à ce que Microsoft clarifie les choses dans sa propre documentation, est de faire des tests réels avant utilisation.