Migrando do texto e da imagem para varchar (max) e varbinary (max)

Eu tenho um banco de dados SQL Server que contém uma série de imagee textcolunas, e eu estou estudando potenciais problemas que possam surgir a partir de migrá-los com os seus homólogos não-obsoletas varbinary(max)e varchar(max).

Além das alterações no código do aplicativo, minha principal preocupação são possíveis "truques" associados a isso. Por exemplo, há funcionalidade suportada pelos tipos de dados mais antigos, mas não nos novos?

A perda de dados devido ao truncamento, pelo menos, não parece ser um problema, pois os novos tipos são pelo menos tão grandes quanto os antigos.

Apenas uma observação: esses novos tipos de dados suportam os mesmos tamanhos dos tipos substituídos que substituem, por exemplo, 2 GB de dados (o que significa um número diferente de caracteres, dependendo do Unicode e de outros fatores).

Uma coisa é certa é que você deve analisar todo o seu código existente aplicação, procedimentos armazenados, funções etc. para instâncias de built-ins, como UPDATETEXT, READTEXT, TEXTPTR, WRITETEXT, TEXTSIZEe @@TEXTSIZE- tudo o que provavelmente terá que ser alterado. Você pode identificar aqueles armazenados no SQL Server desta maneira:

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

Observe que isso pode gerar falsos positivos (por exemplo, esses termos podem estar em um comentário ou ocorrer naturalmente no nome de uma entidade) e pode faltar alguns (por exemplo, os comandos podem ser construídos usando parâmetros / SQL dinâmico). Você está sozinho procurando a base de código do aplicativo e / ou o controle de origem em busca de instâncias do mesmo.

Certifique-se também de encontrar todos os módulos que aceitam ou emitem parâmetros desses 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);

Você também pode considerar que pode ter lógica em tarefas e outras rotinas de manutenção que atualmente evitam essas tabelas ou as tratam de maneira diferente devido às limitações inerentes a esses tipos de dados. Quando você muda para os tipos mais recentes (e especialmente nas versões mais modernas do SQL Server), muitas dessas limitações desaparecem.

Finalmente, além da sintaxe acima, não consigo pensar em um único recurso que os tipos antigos suportem e que os novos não.

Passamos por isso sem problemas. Em qualquer lugar que você estiver atualizando ou inserindo dados, verifique se é uma inserção / atualização tradicional e se não está usando WRITETEXT ou UPDATETEXT.
Fora isso, tudo deve funcionar bem.