SQL Server 静默截断存储过程中的 varchar

根据本次论坛讨论，SQL Server（我使用的是 2005，但我收集这也适用于 2000 和 2008）默默地截断任何varchar您将 varchar 的长度指定为存储过程参数，即使直接使用INSERT实际上会导致错误。例如。如果我创建这个表：

CREATE TABLE testTable(
    [testStringField] [nvarchar](5) NOT NULL
)

然后当我执行以下命令时：

INSERT INTO testTable(testStringField) VALUES(N'string which is too long')

我收到错误：

String or binary data would be truncated.
The statement has been terminated.

伟大的。保留数据完整性，并且调用者知道这一点。现在让我们定义一个存储过程来插入它：

CREATE PROCEDURE spTestTableInsert
    @testStringField [nvarchar](5)
AS
    INSERT INTO testTable(testStringField) VALUES(@testStringField)
GO

并执行它：

EXEC spTestTableInsert @testStringField = N'string which is too long'

没有错误，1 行受到影响。一行被插入到表中，其中testStringField作为“字符串”。 SQL Server 默默地截断了存储过程varchar范围。

现在，这种行为有时可能很方便，但我认为没有办法将其关闭。这非常烦人，因为我want如果我向存储过程传递太长的字符串，就会出错。似乎有两种方法可以解决这个问题。

首先，声明存储过程@testStringField参数大小为 6，并检查其长度是否超过 5。这看起来有点像 hack，并且涉及大量令人恼火的样板代码。

其次，只需将所有存储过程 varchar 参数声明为varchar(max)，然后让INSERT存储过程中的语句失败。

后者似乎工作正常，所以我的问题是：使用是一个好主意吗varchar(max)对于 SQL Server 存储过程中的字符串总是如此，如果我真的希望存储过程在传递太长的字符串时失败？这可能是最佳实践吗？无法禁用的静默截断对我来说似乎很愚蠢。

It just is.

但我从未注意到问题，因为我的检查之一是确保我的参数与表列长度匹配。在客户端代码中也是如此。就我个人而言，我希望 SQL 永远不会看到太长的数据。如果我确实看到了截断的数据，那么造成它的原因就会很明显。

如果您确实觉得需要 varchar(max)，请注意巨大的性能问题，因为数据类型优先级。 varchar(max) 的优先级高于 varchar(n)（最长的优先级最高）。因此，在这种类型的查询中，您将得到扫描而不是查找，并且每个 varchar(100) 值都会被强制转换为 varchar(max)

UPDATE ...WHERE varchar100column = @varcharmaxvalue

Edit:

有一个打开 Microsoft Connect 项目关于这个问题。

它可能值得包含在Erland Sommarkog 的严格设置 (and 匹配的连接项目).

编辑 2，马丁斯评论后：

DECLARE @sql VARCHAR(MAX), @nsql nVARCHAR(MAX);
SELECT @sql = 'B', @nsql = 'B'; 
SELECT 
   LEN(@sql), 
   LEN(@nsql), 
   DATALENGTH(@sql), 
   DATALENGTH(@nsql)
;

DECLARE @t table(c varchar(8000));
INSERT INTO @t values (replicate('A', 7500));

SELECT LEN(c) from @t;
SELECT 
   LEN(@sql + c), 
   LEN(@nsql + c), 
   DATALENGTH(@sql + c), 
   DATALENGTH(@nsql + c) 
FROM @t;