Migración de texto e imagen a varchar (max) y varbinary (max)

Tengo una base de datos de SQL Server que contiene varias columnas imagey text, y estoy estudiando posibles problemas que podrían surgir al migrarlos a sus contrapartes no obsoletas varbinary(max)y varchar(max).

Además de los cambios en el código de la aplicación, mi principal preocupación son las posibles "trampas" asociadas con esto. Por ejemplo, ¿hay funcionalidad compatible con los tipos de datos más antiguos pero no con los nuevos?

La pérdida de datos debido al truncamiento al menos no parece ser un problema ya que los nuevos tipos son al menos tan grandes como los antiguos.

Solo una nota: estos nuevos tipos de datos admiten los mismos tamaños que los tipos obsoletos que reemplazan, por ejemplo, 2 GB de datos (lo que significa una cantidad diferente de caracteres dependiendo de Unicode y otros factores).

Una cosa es segura es que debe analizar todo el código existente de aplicación, procedimientos almacenados, funciones, etc., para los casos de muebles empotrados como UPDATETEXT, READTEXT, TEXTPTR, WRITETEXT, TEXTSIZEy @@TEXTSIZE- todos los cuales probablemente tendrán que ser cambiado. Puede identificar los almacenados en SQL Server de esta manera:

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%';

Tenga en cuenta que esto podría generar falsos positivos (por ejemplo, esos términos pueden estar en un comentario o aparecer naturalmente en el nombre de una entidad) y podría perder algunos (por ejemplo, los comandos podrían construirse usando parámetros / SQL dinámico). Está solo para buscar la base de código de su aplicación y / o el control de origen para instancias de la misma.

También asegúrese de encontrar todos los módulos que acepten o generen parámetros de estos tipos:

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);

También es posible que desee considerar que puede tener lógica en los trabajos y otras rutinas de mantenimiento que actualmente evitan estas tablas o las tratan de manera diferente debido a las limitaciones inherentes a estos tipos de datos. Cuando pasa a los tipos más nuevos (y especialmente en las versiones más modernas de SQL Server), muchas de estas limitaciones desaparecen.

Finalmente, aparte de la sintaxis anterior, no puedo pensar en una sola característica que admitan los tipos antiguos que no admiten los nuevos.

Hemos pasado por esto sin ningún problema. En cualquier lugar donde esté actualizando o insertando datos, asegúrese de que sea una inserción / actualización tradicional y que no esté utilizando WRITETEXT o UPDATETEXT.
Aparte de eso, todo debería funcionar bien.