SQL Server视图GROUP BY报“Cannot resolve collation conflict”是因JOIN或GROUP BY时字符串列排序规则不一致所致；需在语句中显式加COLLATE，或修改列级排序规则并重建视图。

SQL Server视图GROUP BY报“Cannot resolve collation conflict”

这是跨排序规则联接最典型的错误，不是语法错，而是SQL Server在JOIN或GROUP BY时发现两边字符串列的COLLATE不一致，拒绝隐式转换。比如左表字段用SQL_Latin1_General_CP1_CI_AS，右表同名字段却是Chinese_PRC_CI_AS，视图一执行就崩。

临时解法是在视图定义里强制统一：在GROUP BY或ON条件中显式加COLLATE，例如：

SELECT name COLLATE Chinese_PRC_CI_AS, COUNT(*) 
FROM view_a a 
JOIN view_b b ON a.name COLLATE Chinese_PRC_CI_AS = b.name COLLATE Chinese_PRC_CI_AS 
GROUP BY name COLLATE Chinese_PRC_CI_AS

但别只靠这个撑上线——每次写视图都手动加，迟早漏；根本解法是改列级排序规则：

• 查冲突列：SELECT COLUMN_NAME, COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME IN ('table_a', 'table_b') AND DATA_TYPE LIKE '%char%'
• 统一修改（注意锁表）：ALTER TABLE table_a ALTER COLUMN name NVARCHAR(100) COLLATE Chinese_PRC_CI_AS
• 已有视图必须重建：CREATE OR REPLACE VIEW不支持SQL Server，得先DROP VIEW再CREATE VIEW

视图里用UPPER()或LTRIM()后JOIN失败

函数调用会丢失原列的COLLATE，导致JOIN时两边一个带规则、一个变成数据库默认规则（如SQL_Latin1_General_CP1_CI_AS），错误信息还是Cannot resolve collation conflict。

别指望SQL Server自动推导——它不会把UPPER(name)自动继承name的排序规则。必须显式补上：

• 错的写法：ON UPPER(a.name) = UPPER(b.name)
• 对的写法：ON UPPER(a.name) COLLATE Chinese_PRC_CI_AS = UPPER(b.name) COLLATE Chinese_PRC_CI_AS
• 更稳妥：建计算列并持久化+索引，同时指定COLLATE，避免每次运算都丢规则

跨库JOIN视图时排序规则不一致

两个库可能用了不同默认排序规则，即使表结构一样，视图里db1.schema.t1 JOIN db2.schema.t2也会报错。SQL Server不按库级规则合并，它看的是具体列的COLLATE属性。

这时候不能只改目标库的COLLATE——ALTER DATABASE ... COLLATE只影响新对象，老表字段不变。必须逐列处理：

• 确认列当前规则：SELECT name, collation_name FROM sys.columns WHERE object_id = OBJECT_ID('db2.schema.t2')
• 批量生成修改语句（注意备份）：ALTER TABLE db2.schema.t2 ALTER COLUMN col_name VARCHAR(50) COLLATE Chinese_PRC_CI_AS
• 如果无法改源库结构，就在视图里所有涉及跨库字符串比较的地方补COLLATE，别省那几个字符

为什么sp_refreshview对排序规则问题完全无效

sp_refreshview只重绑定列名、类型和NULL性，它不碰COLLATE、不重解析表达式、不检查JOIN条件里的隐式转换。你跑完它返回“命令已成功完成”，视图照样报错。

真正要动的是视图定义本身——用sp_helptext 'your_view'拿到原始SQL，逐行扫JOIN、GROUP BY、ORDER BY、函数调用这四类地方，凡是有字符串参与的，都得人工核对是否加了COLLATE。没有自动方案，也没有银弹。