J'utilise SQL Server 2008 et j'ai besoin d'agrandir un champ VARCHAR, de (200 à 1200) sur une table d'environ 500 000 lignes. Ce que j'ai besoin de savoir, c'est s'il y a des problèmes que je n'ai pas pris en compte.
Je vais utiliser cette instruction TSQL:
ALTER TABLE MyTable
ALTER COLUMN [MyColumn] VARCHAR(1200)
Je l'ai déjà essayé sur une copie des données et cette déclaration n'a eu aucun effet néfaste que je pouvais voir.
Alors, y a-t-il des problèmes possibles liés à cela que je n'ai peut-être pas envisagés?
Au fait, la colonne n'est pas indexée.
Ceci n’est qu’un changement de métadonnées: c’est rapide.
Une observation: spécifiez NULL ou NOT NULL explicitement pour éviter les "accidents" si l'un des paramètres SET ANSI_xx est différent, par exemple, il est exécuté dans osql et non pas SSMS pour une raison quelconque
Je voulais juste ajouter mes 2 centimes, depuis que j'ai googlé cette question parce que je me suis retrouvé dans une situation similaire ...
ATTENTION lors du passage de varchar(xxx)
à varchar(yyy)
, le méta-donnée change, mais passe à varchar(max)
n'est pas. Parce que varchar(max)
, les valeurs (également appelées valeurs BLOB - image/texte, etc.) sont stockées différemment sur le disque, pas dans une ligne du tableau, mais "hors ligne". Ainsi, le serveur deviendra fou sur une grande table et ne répondra plus pendant quelques minutes (heures).
--no downtime
ALTER TABLE MyTable ALTER COLUMN [MyColumn] VARCHAR(1200)
--huge downtime
ALTER TABLE MyTable ALTER COLUMN [MyColumn] VARCHAR(max)
PS il en va de même pour nvarchar
ou bien sûr.
Passer de Varchar (200) à Varchar (1200) ne devrait poser aucun problème, car il ne s'agit que d'un changement de métadonnées et, étant donné que SQL Server 2008 tronque les espaces vides excessifs, aucune différence de performances ne devrait apparaître. En bref, la création du changement.
Une autre raison pour laquelle vous devriez éviter de convertir la colonne en varchar (max) est que vous ne pouvez pas créer d'index sur une colonne varchar (max).