想查出原因並能够掌控自己的程序，戒用設計器是我的一貫忠告。

厨师王德榜大师：我按您的方法添加了事件，可还是没解决。不知是哪出问题了，希望能给予进一步指导，因为我很需要把这问题解决。
如果方便的话，可否给我远程帮忙解决（我QQ：429769628），或给我电话号码，我打电话过去讨教？

程序从XP到WIN7，在字符比较时
在XP中
?表1.字段1=表2.字段1 &&输出是正确的，为 T
在WIN7中
?表1.字段1=表2.字段1 &&输出是有时是错误的，为 F
要改为
?ALLT(表1.字段1)=ALLT(表2.字段1) &&才是正确的

系統不同，C運行庫的機制有改變，字符串比較=算符的算法會改，從而影嚮某些涉及優化的程序。對字符串比較類型的代碼，我歷來祗寫==，不用=的，雖然使用=可以啟動優化，但實際上並不可靠，犧牲可靠性換取速度效率，竊以為不値。程序寫得穩妥，極少會發生與系統變換相關的問題——喜歡使用系統API尤其是偏僻API的最好注意一點，能用語言自己功能解決爲佳。

C運行庫字符串的=比較是怎樣的呢？兩個字符串s1和s1，它不是對s1進行循環就是對s2循環，由於兩個串的長度可能不同，那麽它對哪個進行循環是影嚮結果的。爲了執行效率，祗對其中一個循環，而要精確比較，則需要對兩個都循環一遍，所以速度會慢。C運行庫有可能改動循環對象，從左邊變爲右邊，結果就不相同。vfp和大多數程序一樣，底層是使用系統内置的C運行庫msvc???.DLL，這個庫中函數的機制變了，效果也會變。

在XP和Win7/8/10下vfp的某些檢索結果差異，尤其是涉及優化模式下索引查找的，都會發生這種問題，大致的原因應在這裏。當然，這祇是我個人的猜測性看法，畢竟不是系統和vfp的作者，他們自己才清楚。

C的短路求値，惹來許多麻煩，其實習慣寫C程序的都知道。vfp中Rushmore優化之所以要求使用=而不是==，也是因爲它要用短路求値機制，快就快在省了一趟循環上。爲什麽不可靠，明白它這種快的原理，自然也知道不可靠的原因是這麽來的。

[此贴子已经被作者于2016-2-29 13:22编辑过]

vfp退出歷史舞臺是遲早的事，當Windows全面過渡到UWP模式，它就終結生命，應該是十年八年的事吧。至於堅守XP的，祇能説是無法溝通了。

问题解决了
谢谢大家！谢谢版主、厨师王德榜等，特别要谢的是版主，他给我的启示解决了问题。

    问题出在我两个数据表索引关联模式不一样。以前我一直以为是兼容性问题，但细想又不大可能，自个花了很多时间折腾，没成功。通过我们论坛求助大家，最后是版主吸水佬给我启示解决了问题，我太高兴了。我要再次再次感谢版主。
    我这个经验教训，应该说对这版本过渡期间有很大的警示作用，在今后编程中，如果出现筛选出结果与预想的不一样时，一琮要将这索引模式列为检查的一个重点。

   问题出在我两个数据表索引关联模式不一样。以前我一直以为是版本兼容性问题，但细想又不大可能，自个花了很多时间折腾，没成功。通过我们论坛求助大家，最后是版主吸水佬给我启示解决了问题，我太高兴了。我要再次再次感谢版主。
    我这个经验教训，应该说对这版本过渡期间有很大的警示作用，在今后编程中，如果出现筛选出结果与预想的不一样时，一定要将这索引模式列为检查的一个重点。