从文本和图像迁移到varchar（max）和varbinary（max）

8

我有一个包含许多image和text列的SQL Server数据库，并且我正在研究将它们迁移到未弃用的对varbinary(max)等物和时可能引起的潜在问题varchar(max)。

除了更改应用程序代码外，我主要关心的是与此相关的潜在“陷阱”。例如，旧数据类型是否支持某些功能，而新数据类型不支持这些功能？

至少由于截断而导致的数据丢失似乎不是问题，因为新类型至少与旧类型一样大。

sql-server database-design blob

— 合流
source

11

只需注意：这些新数据类型支持与其替换的不赞成使用的类型相同的大小，例如2GB的数据（这取决于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的最新版本上）时，许多限制都将消失。

最后，除了上面的语法之外，我无法想到旧类型支持的一个功能而新类型则不支持。

— 亚伦·伯特兰
source

2

我们已经经历了这个，没有任何问题。在您要更新或插入数据的任何地方，请确保这是传统的插入/更新，并且您没有使用WRITETEXT或UPDATETEXT。
除此之外，一切都应该正常工作。

— 维克·安布鲁索（Vic Ambruso）
source