表abc.dbf的字段bm是字符型，其中的值结尾带空格
在win7(64位)中输入命令
brow for bm="10#   "     &&引号中值是从表中复制过来的
查询结果为空

brow for bm=alltrim("10#   ")
查询结果也为空

brow for alltrim(bm)=alltrim("10#   ")
查询结果正常,与在xp中brow for bm="10#   "一致。

vfp都是9.0

请问你们是这样的吗？怎样设置在win7中 brow for bm="10#   "才能查出结果。







[ 本帖最后由 zengjun81357 于 2014-4-25 11:20 编辑 ]

还有这不同？不是win7 测试不了

我在 win7（32位）下运行没有问题。请查看一下 set exact 设置，默认应该是 set exact off

你好，不是set exact 原因。晚上回家换台电脑再用win7（64位）测试

用'=='比较

拉不出屎就說地板硬，動不動就懷疑Win7/Win8、64位等，哧～又是從來不看別人說用這個多年沒問題的。

假定set exact狀態設置，以及在不同的環境（系統、版本）下出現問題，都是程序編寫有疏漏的表現。程序員“不要做過多的假定”這條戒律，不知為何總有那麽多人不遵守的。無非是貪方便，求“效率”，殊不知上帝很公平，省了的東西必須補回來，代價就是在運行時出問題，帶來更大的維護成本，因爲程序投入運行之後，維護就不單是程序的問題了，還有實際數據、人員重新培訓等問題，那可是用錢算的。省這麽點代碼，貪圖幾秒、幾分鐘的快速，値得嗎？

[ 本帖最后由 TonyDeng 于 2014-4-26 13:41 编辑 ]

很多人都（從書上）知道，用=號比較比用==快，所以偏愛用=，但實際上他們並沒意識到現實中的數據空格在比較號的兩邊變量中都可能出現，有表字段自動填充的，也有輸入控件自帶的，也有用戶輸入不規範造成的等等，可能性極多，若總以爲某一邊的數據是規範的，依賴exact設定用=號求結果，在某些測試場合正確，不等於在任何場合都正確。爲了省那麽點時間，嚴重依賴=，在表數據中有錯誤記錄的時候就出現遺漏（漏查，因爲它們不符合篩選條件），祗能給現實工作帶來麻煩。

==之所以比=慢，是因爲它的比較是要對兩邊的串都掃描一遍，而後者僅掃描一邊，在字符串不是非常長或比較集合非常大的情況下，這種消耗是微不足道的，追那快速幹嘛。

本來排查這種錯誤很簡單，用MessageBox()彈出比較時符號兩邊的變量看看內容就知道為什麽比較不成功了。這麽點基本的調試手段，總不見有人願意學，敎也不聽。