sql-server - 从 ntext 转移到 nvarchar(max) 有什么问题吗

Question

将我的列类型从 text/ntext 更改为 varchar(max)/nvarchar(max) 是否有任何问题？

它能破坏任何东西吗？例如，具有 ntext 参数的存储过程...

Answer 1

有一些问题，例如，如果您当前正在使用以下功能:

• UPDATETEXT
• WRITETEXT
• READTEXT
• TEXTPTR

您可能想要搜索您的代码库以识别这些 - 如果您使用即席 SQL，则搜索您的应用程序和/或源代码控制，或者使用以下方法搜索存储过程等:

SELECT OBJECT_SCHEMA_NAME([object_id]), OBJECT_NAME([object_id])
  FROM sys.sql_modules
  WHERE [definition] LIKE '%WRITETEXT%'
     OR [definition] LIKE '%READTEXT%'
     OR [definition] LIKE '%UPDATETEXT%'
     OR [definition] LIKE '%TEXTPTR%';

您还可以使用这些参数(我同时包含了 TEXT 和 NTEXT)来识别过程和函数:

SELECT OBJECT_SCHEMA_NAME([object_id]), OBJECT_NAME([object_id]), name
  FROM sys.parameters
  WHERE system_type_id IN (35, 99);

具有这些列类型的表/ View /TVF 使用:

SELECT OBJECT_SCHEMA_NAME([object_id]), OBJECT_NAME([object_id]), name
  FROM sys.columns
  WHERE system_type_id IN (35, 99);

或者 - 我不确定所有的 API/提供者 - 但有些人可能在将 ntext 参数换成 nvarchar 时遇到问题(你可能必须明确更改您的一些代码指定最大长度为 -1)。当这些类型仍然流行时(~1999)，我已经很长时间没有编写接口(interface)代码了，所以如果我的内存在那里模糊不清，我深表歉意。

如果您的存储过程继续采用 NTEXT 参数，您不应该进行任何重大更改，但您不希望长期保留这些参数。

大多数情况下，您应该会体验到更好的性能、更轻松的数据操作以及与新类型的整体改进的兼容性。没关系面向 future !