我用set exact on 结果也是这样，查过资料,set exact on 不适用vfp的 SQL,我前天统计数据时发现这问题

[ 本帖最后由 kiff 于 2013-3-25 11:22 编辑 ]

in是SQL的语法，SQL语法并不是VFP语言本身设计的，它怎么工作是这个指令体系自己的事，我从来回避用SQL指令，不知道，你说的不适用是指在in参数下。在inlist()中，就归VFP管，你测试一下inlist("02", "0201")和inlist("0201", "02")的返回结果就知道了。

测试了,以下结果一样。
inlist(DM,"02", "0201")和inlist(DM,"0201", "02") 、DM IN ("02", "0201")、DM IN ("0201", "02")
如果是sqlserver 或 oracle ,DM IN ("02", "0201")就没这问题



[ 本帖最后由 kiff 于 2013-3-25 11:31 编辑 ]

VFP执行INLIST("0201", "02")函数，转换为逻辑判断"0201"="02"，在set exact off下，这个结果为真，反之为假。

是的，在命令窗口测试，如 ?INLIST("0201", "02"),确是这结果，但用在 vfp SQL  就不一样了.

INLSIT(x, v1, v1, v3)的用法是测试x是否与后面的列表v1、v2、v3有匹配，任何一个匹配都返回真。你上面的两个INLIST()其实是同一个语句，结果当然一样了。

我对字符串比较，从来都使用==精确比较，对INLIST()，不用于字符串。==会使执行速度减慢，但不会出错。VFP的查询和搜索会启动Rushmore优化加速，其中的手段之一就是对=使用简化比较法，当指令含有==算符时，不会启动Rushmore，所以这个时候会慢。这些细微的地方，在用于SQL时，是要注意的，毕竟VFP是用自己的方法实现SQL的结果，它并非完全与SQL Server兼容，正如各种不同厂家和平台的C/C++编译器的实现方法有差异一样。在SQL Server中，好像没有INLIST()函数，但在VFP的SQL指令中有，就说明这是厂家差异。

现找到解决这问题的初步办法(还需大量数据验证)。
办法就是在各字符子串后加上一个空格
如 INLIST(dm,'0202 ','02 ')
或 dm in ('0202 ','02 ')
--------------------------
现在发现多加的这空格很奥妙，
select * from 表 where  dm='02 ' &&多了一个空格
select * from 表 where  dm=='02'
以上这两句是等价的

而下面的结果就非常不一样了.
select * from 表 where  dm='02' &&没加空格




[ 本帖最后由 kiff 于 2013-3-25 17:43 编辑 ]

我的做法
Set Exact On

并且比较的时候使用 ==