Migration de texte et d'image vers varchar (max) et varbinary (max)

J'ai une base de données SQL Server qui contient un certain nombre de imageet textcolonnes, et j'étudie les problèmes potentiels qui pourraient découler de leur migration vers leurs homologues non dépréciées varbinary(max)et varchar(max).

Mis à part les modifications apportées au code d'application, ma principale préoccupation concerne les "pièges" potentiels associés à cela. Par exemple, des fonctionnalités sont-elles prises en charge par les anciens types de données, mais pas par les nouveaux?

La perte de données due à la troncature au moins ne semble pas être un problème car les nouveaux types sont au moins aussi grands que les anciens.

Juste une note: ces nouveaux types de données prennent en charge les mêmes tailles que les types obsolètes qu'ils remplacent, par exemple 2 Go de données (ce qui signifie un nombre différent de caractères selon Unicode et d'autres facteurs).

Une chose est sûre , vous devez analyser l' ensemble de votre code d'application, procédures stockées, fonctions , etc. pour les instances de built-ins tels que UPDATETEXT, READTEXT, TEXTPTR, WRITETEXT, TEXTSIZEet @@TEXTSIZE- qui sera susceptible d'être modifié. Vous pouvez identifier ceux stockés dans SQL Server de cette façon:

SELECT s.name, o.name
  FROM sys.sql_modules AS m
  INNER JOIN sys.objects AS o
  ON m.[object_id] = o.[object_id]
  INNER JOIN sys.schemas AS s
  ON o.[schema_id] = s.[schema_id]
  WHERE UPPER(m.definition) LIKE N'%UPDATETEXT%'
     OR UPPER(m.definition) LIKE N'%WRITETEXT%'
     OR UPPER(m.definition) LIKE N'%READTEXT%'
     OR UPPER(m.definition) LIKE N'%TEXTPTR%'
     OR UPPER(m.definition) LIKE N'%TEXTSIZE%';

Notez que cela pourrait produire des faux positifs (par exemple, ces termes peuvent être dans un commentaire ou se produire naturellement dans un nom d'entité) et cela pourrait en manquer (par exemple, les commandes pourraient être construites à l'aide de paramètres / SQL dynamique). Vous êtes seul pour rechercher dans la base de code de votre application et / ou le contrôle de code source des instances de la même chose.

Assurez-vous également de trouver tous les modules qui acceptent ou émettent des paramètres de ces types:

SELECT DISTINCT s.name, o.name
  FROM sys.parameters AS p
  INNER JOIN sys.objects AS o
  ON p.[object_id] = o.[object_id]
  INNER JOIN sys.schemas AS s
  ON o.[schema_id] = s.[schema_id]
  WHERE system_type_id IN (34,35,99);

Vous pouvez également considérer que vous pouvez avoir une logique dans les travaux et autres routines de maintenance qui évitent actuellement ces tables ou les traitent différemment en raison des limitations inhérentes à ces types de données. Lorsque vous passez aux types les plus récents (et en particulier sur les versions les plus modernes de SQL Server), beaucoup de ces limitations disparaissent.

Enfin, à part la syntaxe ci-dessus, je ne peux pas penser à une seule fonctionnalité prise en charge par les anciens types que les nouveaux types ne prennent pas en charge.

Nous avons vécu cela sans aucun problème. Partout où vous mettez à jour ou insérez des données, assurez-vous qu'il s'agit d'une insertion / mise à jour traditionnelle et que vous n'utilisez pas WRITETEXT ou UPDATETEXT.
A part ça, tout devrait bien fonctionner.