亲爱的pb程序员小伙伴们，你是否曾经也被dw的find和setfilter莫名其妙的错误搞的焦头烂额？已经有不少小伙伴们跟我抱怨过了，当告诉他们怎么修改后，很多小伙伴会回敬一句：“高手啊！”，直到今天，终于有个小伙伴说了一句：“为什么这样修改就好了呢？搞不明白！”，然后，心血来潮我就答应他，让他晚些时候，关注一下我的公众号。我决定将原理跟大家说一下，期望以后大家再碰到此类问题，能够知其然知其所以然。
他调用的是dw的find方法，方法参数是
他告诉我，一直报错，返回-5。但是把这个参数放到sql的where条件里面却不会报错。
首先，我要说的是，dw的find方法参数跟sql的where条件是风马牛不相及的两个概念。find的方法参数是一个字符串，它代表的是一个string expression(字符串表达式)。该字符串表达式的计算结果必须是一个boolean值。执行find方法就是查找字符串表达式的计算结果为true的记录，找到后，返回该记录对应的行号。前面小伙伴的程序返回-5的错误码就是因为字符串表达式的计算结果不是boolean型。
但是小伙伴不高兴啊，我的字符串怎么会不是boolean型呢，明明都是and组成的。问题出在like上面，要将BRXZ LIKE '%37%'修改成(BRXZ LIKE '%37%')。小伙伴还是不能接受，因为单独摘出如下图所示的一部分，
BRXZ LIKE '%37%'没加括号却运行正常。
我们先来分析一下这个原因。一个字符串表达式的计算结果是否是boolean型需要系统去计算的，单独摘出前面一段不报错是因为LIKE出现在了字符串表达式的最后，后面没有任何字符了，系统完全能够确定该表达式是boolean型。但是，对于整个字符串表达式来说，系统无法确定它是boolean型。因为，LIKE 后面一直没有出现 BRXZ条件结束的标志，有人可能说后面有空格啊，但是pb不认为空格就是当前条件结束的标志，因为，你完全可以写成 BRXZ LIKE '%37%' +'%38%'，又有人可能会说空格不能代表结束，AND总可以了吧，毕竟sql里面AND就可以代表前面条件的结束，但是很不幸，pb里面不认可这个东西，你可以认为这个是pb的bug，你也可以认为这是pb为了偷懒，没去处理这种逻辑。但是小括号的右括号，pb是认可的，这也就是要将BRXZ LIKE '%37%'修改成(BRXZ LIKE '%37%')的原因。
事情远没有这么简单，LIKE的问题处理完后，小伙伴说还是返回-5啊，问题根本不是出在这里，但是这个我要反驳的，pb也是够懒的，因为-5的错误码代表的是参数错误，并不代表具体的错误原因。其实这次的-5是另一个错误，Types of expressions must match(表达式的类型必须匹配)。我们一眼就可以看到KSRQ和JSRQ是个时间类型，但是他却跟字符串类型进行了比较，所以此处需要将时间属性比较的值转换成时间类型。转换后的时间部分的表达式如下图所示。
至此，小伙伴的程序终于运行正确了。
错误代码-5代表的是不是就这两种情况了呢，当然不是，find方法接收的是字符串表达式，编译的时候只要是字符串就可以了，至于这个字符串能不能计算出boolean型，只有运行的时候才知道，所以这个字符串参数可以写入任何无意思的字符串。所以，它还有一种错误就是Expression is not valid(表达式无效)。
setfilter方法使用的也是字符串表达式，意义跟find完全一样，所以弄明白了find的用法，setfilter的用法也清楚了。
小伙伴们，以后再遇到这两个方法的时候，是不是会得心应手了呢？我们拭目以待。
