Миграция с текста и изображения на varchar (max) и varbinary (max)

У меня есть база данных SQL Server , которая содержит ряд imageи textстолбцов, и я изучаю потенциальные проблемы , которые могут возникнуть в результате миграции их в не-устаревших аналоги varbinary(max)и varchar(max).

Помимо изменений в коде приложения, моей главной проблемой являются потенциальные "ошибки", связанные с этим. Например, есть ли функциональность, поддерживаемая старыми типами данных, но не в новых?

По крайней мере, потеря данных из-за усечения, по-видимому, не является проблемой, поскольку новые типы по крайней мере такие же большие, как и старые.

Просто обратите внимание: эти новые типы данных поддерживают те же размеры, что и устаревшие типы, которые они заменяют, например, 2 ГБ данных (что означает различное количество символов в зависимости от Unicode и других факторов).

Одна вещь наверняка, вы должны проанализировать все существующие кода приложений, хранимых процедур, функций и т.д. для экземпляров встроенных модулей , таких как UPDATETEXT, READTEXT, TEXTPTR, WRITETEXT, TEXTSIZEи @@TEXTSIZE- все из которых, вероятно , должны быть изменены. Вы можете определить те, которые хранятся в SQL Server следующим образом:

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

Обратите внимание, что это может привести к ложным срабатываниям (например, эти термины могут быть в комментарии или естественным образом встречаться в имени объекта), и некоторые из них могут пропустить (например, команды могут быть созданы с использованием параметров / динамического SQL). Вы по своему усмотрению ищите в базе кода приложения и / или в контроле исходного кода экземпляры того же самого.

Также убедитесь, что вы найдете все модули, которые принимают или выводят параметры этих типов:

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

Вы также можете подумать, что у вас может быть логика в заданиях и других процедурах обслуживания, которые в настоящее время избегают этих таблиц или обрабатывают их по-разному из-за ограничений, присущих этим типам данных. При переходе на новые типы (и особенно в самых современных версиях SQL Server) многие из этих ограничений исчезают.

Наконец, кроме синтаксиса, приведенного выше, я не могу представить себе ни одной функции, которую старые типы поддерживают, а новые типы не поддерживают.

Мы прошли через это без каких-либо проблем. Везде, где вы обновляете или вставляете данные, убедитесь, что это традиционная вставка / обновление и что вы не используете WRITETEXT или UPDATETEXT.
Кроме этого, все должно работать нормально.