J'ai inséré des enregistrements dans une table de base de données SQL Server. La table avait une clé primaire définie et la graine d'identité à incrémentation automatique était définie sur "Oui". Ceci est fait principalement parce que dans SQL Azure, chaque table doit avoir une clé primaire et une identité définies.
Mais comme je dois supprimer certains enregistrements de la table, la graine d'identité pour ces tables sera perturbée et la colonne d'index (qui est générée automatiquement avec un incrément de 1) sera perturbée.
**Comment puis-je réinitialiser la colonne d'identité après avoir supprimé les enregistrements afin que la colonne ait une séquence dans l'ordre numérique croissant ?
La colonne identité n'est pas utilisée comme clé étrangère dans la base de données.
La commande de gestion [DBCC CHECKIDENT
][1] est utilisée pour réinitialiser le compteur d'identité. La syntaxe de la commande est la suivante :
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 l'est maintenant.
Veuillez noter que l'argument new_reseed_value
varie selon les versions de SQL Server [selon la documentation][2] :
Si des lignes sont présentes dans la table, la ligne suivante est insérée avec la valeur new_reseed_value. Dans les versions SQL Server 2008 R2 et antérieures, la ligne suivante insérée utilise new_reseed_value + la valeur d'incrémentation actuelle.
Cependant, Je trouve cette information trompeuse (tout simplement fausse en fait) car le comportement observé indique qu'au moins SQL Server 2012 utilise toujours la logique new_reseed_value + la valeur d'incrément actuelle. Microsoft contredit même avec son propre Exemple C
trouvé 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 La colonne AddressTypeID de la table AddressType a une valeur de 10. Étant donné que la table comporte des lignes existantes, la prochaine ligne insérée utilisera 11 comme valeur, c'est-à-dire la nouvelle valeur d'incrémentation actuelle définie pour la colonne La valeur de la colonne 11 > plus 1.
USE AdventureWorks2012;
GO
DBCC CHECKIDENT ('Person.AddressType', RESEED, 10);
GO
Néanmoins, tout ceci laisse une option pour un comportement différent sur les versions plus récentes 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 l'utilisation.
[1] : http://technet.microsoft.com/en-us/library/ms176057.aspx [2] : https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkident-transact-sql