En SQL 2005 et supérieur, il existe une astuce pour résoudre ce problème sans modifier les pages de données de la table. C'est important pour les grandes tables où toucher chaque page de données peut prendre des minutes ou des heures. L'astuce fonctionne également si la colonne d'identité est une clé primaire, si elle fait partie d'un index clusterisé ou non clusterisé, ou d'autres problèmes qui peuvent faire échouer la solution plus simple "ajouter/supprimer/renommer la colonne".
Voici l'astuce : vous pouvez utiliser la fonction MODIFIER LA TABLE...CHANGER pour modifier le schéma d'une table sans modifier les données, ce qui signifie que vous pouvez remplacer une table avec une IDENTITÉ par un schéma de table identique, mais sans colonne d'IDENTITÉ. La même astuce fonctionne pour ajouter l'IDENTITÉ à une colonne existante.
Normalement, MODIFIER LA TABLE...CHANGER est utilisé pour remplacer efficacement une partition pleine dans une table partitionnée par une nouvelle partition vide. Mais elle peut également être utilisée dans des tables non partitionnées.
J'ai utilisé cette astuce pour convertir, en moins de 5 secondes, une colonne d'une table de 2,5 milliards de lignes d'IDENTITY en non-IDENTITY (afin d'exécuter une requête de plusieurs heures dont le plan de requête fonctionnait mieux avec des colonnes non-IDENTITY), puis j'ai rétabli le paramètre IDENTITY, toujours en moins de 5 secondes.
Voici un exemple de code qui illustre son fonctionnement.
CREATE TABLE Test
(
id int identity(1,1),
somecolumn varchar(10)
);
INSERT INTO Test VALUES ('Hello');
INSERT INTO Test VALUES ('World');
-- copy the table. use same schema, but no identity
CREATE TABLE Test2
(
id int NOT NULL,
somecolumn varchar(10)
);
ALTER TABLE Test SWITCH TO Test2;
-- drop the original (now empty) table
DROP TABLE Test;
-- rename new table to old table's name
EXEC sp_rename 'Test2','Test';
-- see same records
SELECT * FROM Test;
C'est évidemment plus compliqué que les solutions proposées dans les autres réponses, mais si votre table est grande, cela peut vous sauver la vie. Il y a quelques mises en garde :
- vous devrez abandonner les clés étrangères avant de faire l'échange et les restaurer après.
- de même pour les fonctions WITH SCHEMABINDING, les vues, etc.
- Les index de la nouvelle table doivent correspondre exactement (mêmes colonnes, même ordre, etc.).
- L'ancienne et la nouvelle table doivent être dans le même groupe de fichiers.
- ne fonctionne que sur SQL Server 2005 ou plus récent
- Je pensais auparavant que cette astuce ne fonctionnait que sur les éditions Enterprise ou Developer de SQL Server (parce que les partitions ne sont prises en charge que dans les versions Enterprise et Developer), mais Mason G. Zhwiti, dans son commentaire ci-dessous, indique qu'elle fonctionne également dans SQL Standard Edition. Je suppose que cela signifie que la restriction à Enterprise ou Developer ne s'applique pas à ALTER TABLE...SWITCH.
Il y a une bonne article sur TechNet détaillant les exigences ci-dessus.