IF 语句中的 SQL Server 排序规则问题（消息 468，级别 16，状态 9）

Question

我的问题出现在“简单即用”的 IF 语句中，这使得对许多类似问题的建议修复（例如无法解决我的查询中的排序规则冲突）似乎毫无用处。

错误信息是：

消息 468，级别 16，状态 9，过程 #XYZ，第 11 行
无法解决 equal to 操作中“Latin1_General_CI_AS”和“SQL_Latin1_General_CP1_CI_AS”之间的排序规则冲突。

众所周知，服务器排序SQL_Latin1_General_CP1_CI_AS设置为SQL_Latin1_General_CP1_CI_AS 。

此查询演示了问题：

-- this procedure (which gets put into tempdb) is called WITHOUT specifying @Choice  
CREATE PROCEDURE #XYZ 
(
    -- all other parameters removed (none of them have default values)
    @Choice AS NVARCHAR(1) = 'Y' 
)
AS  
BEGIN
    IF (@choice = 'Y')  -- error raised here 
    BEGIN
        DECLARE @NULL_STATEMENT AS int -- only here because there's no "do nothing" statement
    END 
    RETURN
END

鉴于不会发生更改服务器（和/或所有表）的默认排序规则，并且在所有查询、表等中插入“COLLATE DATABASE_DEFAULT”是不切实际的（为此，我该如何解决此问题）解决方案参见https://www.mssqltips.com/sqlservertip/4395/understanding-the-collat​​e-databasedefault-clause-in-sql-server/和无法解决临时表和 sys.objects 之间的排序规则冲突）。

密切相关的链接：

COLLATE 子句的文档： https ://docs.microsoft.com/en-us/sql/t-sql/statements/collat​​ions ? view = sql-server-2017

我可能无法使用的解决方案： https : //www.mssqltips.com/sqlservertip/2901/how-to-change-server-level-collat​​ion-for-a-sql-server-instance/

Answer 1

（来自当前接受的答案）：

修复是将默认参数从 ASCII (varchar) 更改为 nvarchar (UTF-8) 形式

1. 不，这并没有解决它。 由于在解析 T-SQL 时将值转换为NVARCHAR （由于参数/变量为NVARCHAR ）并且此错误发生在编译时，因此该特定更改没有任何影响。
2. 这个问题与NVARCHAR 、 UTF-8 甚至参数默认值完全无关。
3. 此处未使用 UTF-8。 SQL Server 只看到 UTF-16，因为这是驱动程序传输的 Unicode 字符串（即 TDS/表格数据流）。 即使使用 UTF-8 归类（SQL Server 2019 中的新功能），该编码也仅用于VARCHAR类型，因为NVARCHAR仅是 UTF-16（Little Endian）。

您遇到的问题是在临时存储过程（本地和全局）中发现的几种“奇怪”行为之一。 对于临时存储过程，参数和变量将始终具有与tempdb排序规则匹配的排序规则，而字符串文字将使用执行CREATE PROCEDURE语句的数据库的排序规则。 这两个排序规则不会改变（对于模块的主 T-SQL 上下文），即使您使用除了[tempdb]和创建临时 proc 的数据库之外具有不同默认排序规则的另一个数据库（尽管动态 SQL 在一个临时存储过程将使用当前数据库的排序规则！有趣，嗯？）。

因此，正如 Martin Smith 在对该问题的评论中所说的那样，在使用N前缀参数值之后执行CREATE PROCEDURE语句时，您必须更改了“当前”/“活动”数据库。

以下示例是问题中显示的代码的简化版本，但清楚地表明，在字符串文字前加上N并不能防止错误发生。

在排序规则与[tempdb]不同的数据库中执行以下 T-SQL：

-- The two returned collations need to be different, else no error with CREATE PROC:
SELECT DATABASEPROPERTYEX(N'tempdb', 'collation') AS [tempdb collation],
       DATABASEPROPERTYEX(DB_NAME(), 'collation') AS [current DB collation];


SET NOEXEC ON;

GO
CREATE PROCEDURE #XYZ
(
  @Choice NVARCHAR(5) = N'Y'
)
AS  
BEGIN
  IF (@Choice = N'Y') PRINT 'yup';
END;
GO

SET NOEXEC OFF;

/*
Msg 468, Level 16, State 9, Procedure #XYZ, Line XXXXX [Batch Start Line YYYYY]
   Cannot resolve the collation conflict between "{current_DB_collation}" and
   "{tempdb_collation}" in the equal to operation.
*/

（来自当前接受的答案）：

奇怪的是，在运行该版本后，我能够删除前导N并且查询没有问题。

正确的。 这是因为N前缀实际上与错误或修复它没有任何关系。 您只是在一个具有与[tempdb]排序SQL_Latin1_General_CP1_CI_AS匹配的SQL_Latin1_General_CP1_CI_AS排序SQL_Latin1_General_CP1_CI_AS的[tempdb] 。

---

_{我正在写一篇博客文章，详细介绍了临时存储过程的几种奇怪行为，包括这种整理的东西。 如果/当我完成它时，我会尽量记住使用指向它的链接更新此答案。}

Answer 2

我总结了@Sean Lange 提供的答案（@Lamak 评论的变体），因为它在我接受之前已被删除。

问题（有关详细信息，请参阅对原始问题的评论）是我遇到了问题！ 将工作代码移动到新服务器时。 修复方法是将默认参数从 ASCII (varchar) 更改为 nvarchar (UTF-8) 形式：

CREATE PROCEDURE #XYZ 
(
    -- all other parameters removed (none of them have default values)
    @Choice AS NVARCHAR(1) = N'Y'  -- Note the leading N
)
AS 
....

奇怪的是，在运行该版本后，我能够删除前导 N 并且查询没有问题。