*** 请邹老大或者各位高手帮忙，非常妖怪的问题，可能和SQLServer的“排序规则”有关系 ***

Question

我的同一个SQL查询语句，执行几次每次返回的结果行数都不一样。
请注意，相关的两个表的数据绝对不会改变，因为我是备份出来的。
下面是我的SQL:SELECT tblMO.COMNO, tblCO.IsClose, tblMO.* 
FROM tblMOBak AS tblMO, tblCOBak AS tblCO
WHERE tblMO.OrderNO = tblCO.CONo 
AND IsNull(tblCO.IsClose, '0') = '0'非常简单的SQL吧，奇怪，但同样的SQL在我的开发机器上就不会有
这个问题。出问题的是我的服务器(Win2000+SQL2000服务器版本)
我本机是(XP+SQLServer2000开发版），两机器数据库的排序规则
都是一样的Chinese_PRC_CI_AS，字段的排序规则是default我查了很长，发现我把SQL改成这样就没有问题了。SELECT tblMO.COMNO, tblCO.IsClose, tblMO.* 
FROM tblMOBak AS tblMO, tblCOBak AS tblCO
WHERE tblMO.OrderNO = tblCO.CONo 
AND IsNull(tblCO.IsClose COLLATE Chinese_PRC_CI_AI, '0') = '0'这样就好了，请问这是怎么回事？？？
（其中,IsClose是个char(1)字段）这个问题非常严重，造成我们的系统里面很多SQL语句都有可能出现
类似的莫名其妙的问题，我们又不可能逐一去改，工作量也太大了？请问是怎么回事，怎么处理？？

Answer 1

SELECT tblMO.COMNO, tblCO.IsClose, tblMO.* 
FROM tblMOBak AS tblMO, tblCOBak AS tblCO
WHERE tblMO.OrderNO = tblCO.CONo 
AND tblCO.IsClose is null

Answer 2

Chinese_PRC_CI_AS --表示區分重音
Chinese_PRC_CI_AI --表示不區分重音

Answer 3

呵呵。。
SELECT tblMO.COMNO, tblCO.IsClose, tblMO.* 
FROM tblMOBak AS tblMO, tblCOBak AS tblCO
WHERE tblMO.OrderNO = tblCO.CONo 
AND (tblCO.IsClose IS NULL OR tblCO.IsClose='0')这个正确不？

Answer 4

是排序规则的问题
alter table tblCOBak
alter column IsClose [char](1) COLLATE Chinese_PRC_CI_AS

Answer 5

问题不在怎么写而在于默认COLLATE，为什么IsNull(tblCO.IsClose, '0') = '0'
有问题waiting高手解答

Answer 6

写错了,应该是这样
alter table tblCOBak
alter column IsClose [char](1) COLLATE Chinese_PRC_CI_AI

Answer 7

对啊，同意xiequanqin(XQQ) 的我已经说了，问题不在于怎么写个SQL语句能解决这一个SQL语句的问题，我的数据库有２００张以上的表，系统开发了几千个SQL，不可能一个个去改把。我要弄清楚的是，为什么？？请邹老大和各位高手回答

Answer 8

我的IsClose字段是char(1)，里面只有三种值，0、1、NULL，和重音不重音有啥关系？？就算有关系，没道理每次查询的结果行数都不一样吧

Answer 9

有没可能跟tblMO.OrderNO = tblCO.CONo 有关系？
把COLLATE Chinese_PRC_CI_AI 换个地方看看

Answer 10

估计 IsClose 的排序规则不是 Chinese_PRC_CI_AI,而你现在运行SQL 语句的服务器默认的排序规则是 Chinese_PRC_CI_AI, 查询的时候就会出现以上的情况.

Answer 11

xiequanqin(XQQ) 
多谢你的回答，我试过，加在tblMO.OrderNO = tblCO.CONo 后面也不行
hlq8210(影子) 我就在服务器上运行也是同样的问题，数据库的缺省排序规则是“Chinese_PRC_CI_AS”，
为什么要改变成"Chinese_PRC_CI_AI"呢，不改就会出莫名其妙的东西？我的机器也是
一样的排序规则，为什么不改就可？

Answer 12

我就在服务器上运行也是同样的问题，数据库的缺省排序规则是“Chinese_PRC_CI_AS”，
为什么要改变成"Chinese_PRC_CI_AI"呢，不改就会出莫名其妙的东西？我的机器也是
一样的排序规则，为什么不改就可？
----------------------------------
打开 IsClose 结构脚本看看 排序规则是否都是 
  Chinese_PRC_CI_AS

Answer 13

2k里面排序规则有好几个级别的！服务器级别的、数据库级别的、表级别的，也许你创建的表在 create或者alter的时候是从其它数据库DTS或者直接通过编辑脚本（自动生成的创建脚本一般参数非常详细，每个字段的collate都包含），你看看这张tblCOBak表是否字段排序有问题！
简单点，在查询分析器里打开对象浏览器，选中你操作的这张表，选择右键菜单在新窗口中编写对象脚本-〉创建，打开的脚本你看看这个字段的排序规则怎么样的

Answer 14

foxyz(如风) 
你好，按你的说法生成了排序规则是对的。是
[IsClose] [char] (1) COLLATE Chinese_PRC_CI_AS NULL 
和数据库的默认排序规则是一样的

Answer 15

hlq8210(影子)是的
--------------
期待高手出现

Answer 16

又仔细作了测试，发现可能跟我表中使用了一些nvarchar的字段有关系测试结果如下：首先，把表中的数据导出到CSV文件（已保证出来的数据没有什么字符集、排序规则的问题）然后作了下面两种不同的动作1、表删除重建，按原来的结构（就是说还有nvarchar字段），再导入CSV文件后，错误依然存在
2、表删除重建，不按原来的结构（就是说把所有的nvarchar字段换成varchar），再导入CSV文件后，错误解决

Answer 17

那么再请问大家，是nvarchar的问题吗？为什么？此外，我的数据库还是必须使用nvarchar字段，没有办法，数据中有不同国家的语言

Answer 18

nvarchar [(n)]:
如果没有在数据定义或变量声明语句中指定 n，则默认长度为 1。如果没有使用 CAST 函数指定 n，则默认长度为 30。如果列数据项的大小可能相同，请使用 nchar。如果列数据项的大小可能差异很大，请使用 nvarchar。为使用 nchar 或 nvarchar 的对象分配的是默认的数据库排序规则，但可使用 COLLATE 子句分配特定的排序规则。SET ANSI_PADDING ON 永远适用于 nchar 和 nvarchar。SET ANSI_PADDING OFF 不适用于 nchar 或 nvarchar 数据类型。COLLATE ：
创建或更改表列：
可以使用 CREATE TABLE 或 ALTER TABLE 语句的 COLLATE 子句指定每个字符串列的排序规则。还可以在使用 SQL Server Management Studio 创建表时指定排序规则。如果不指定排序规则，将为列分配数据库的默认排序规则。 转换表达式的排序规则：
可以使用 COLLATE 子句将字符表达式转换为某个排序规则。为字符文本和变量分配当前数据库的默认排序规则。为列引用分配列的定义排序规则。COLLATE 子句只能应用于 char、varchar、text、nchar、nvarchar 和 ntext 数据类型。排序规则标签  对象的类型  
强制默认
 任何 Transact-SQL 字符串变量、参数、文字、目录内置函数的输出或不使用字符串输入但生成字符串输出的内置函数。如果在用户定义函数、存储过程或触发器中声明对象，则为该对象分配创建函数、存储过程或触发器所采用的数据库默认排序规则。如果在批处理中声明对象，则为该对象分配用于连接的当前数据库的默认排序规则。
 
隐式 X
 列引用。从为表或视图中的列定义的排序规则得到表达式 (X) 的排序规则。即使使用 CREATE TABLE 或 CREATE VIEW 语句中的 COLLATE 子句为列显式分配了排序规则，该列引用仍归为隐式。
 
显式 X
 使用表达式中的 COLLATE 子句显式转换为特定排序规则 (X) 的表达式。
 
无排序规则
 指示表达式的值是两个字符串之间的运算结果，而这两个字符串具有隐式排序规则标签的冲突排序规则。表达式的结果被定义为不具有排序规则。
 排序规则
只引用一个字符串对象的简单表达式的排序规则标签是被引用对象的排序规则标签。如果复杂表达式被引用两个操作数表达式的排序规则标签相同，则该复杂表达式的排序规则标签为操作数表达式的排序规则标签。如果复杂表达式被引用两个操作数表达式的排序规则不同，则该复杂表达式最终结果的排序规则标签基于下列规则： 显式优先于隐式。隐式优先于强制默认:  ----------------------------------------------------------------------------
建议建表时指定 隐式 X

Answer 19

http://community.csdn.net/Expert/topic/5275/5275251.xml?temp=8.370608E-02各位好心人，帮我看看吧。

Answer 20

select collation from syscolumns 
where id=object_id(yourtablename)

Answer 21

各位，这个问题还有一些比较奇怪的现象，是我后面测试出来的此外，我如果把SELECT后面的tblMO.*改成具体的字段名的化，就会发现一个非常奇怪的问题：
比如该表有70个字段，
如果只SELECT比较少的字段（比如20个左右的化），那么查询结果是对的（大约12000行）
如果再多SELECT几个字段（比如：50个左右），那么查询结果就只有9000多行了
如果再多SELECT几个字段（比如：70个左右），那么查询结果就只有6000多行了

Answer 22

各位，问题解决了，SQLServer本身的Bug。
Microsoft的相关说明：
http://support.microsoft.com/kb/326314/en-us我的SQLServer是没有打过补丁的。今天我打上SQLServer的SP4后，问题解决。最后，多谢各位高手的关注和帮忙。尤其是：
xiequanqin(XQQ) 和hlq8210(影子)两位。