如果记录多的话, 一般不宜用scan/endscan的, 那样速度将会超慢~
如果字段少的话, 可以用update~
如果记录多, 字段也多的话, 最快的方法是:
repl all 字段1 with iif(empt(字段1),"0",字段1);
,字段2 with iif(empt(字段2),"0",字段2);
....
上述的 repl语句也可以通过 for i=1 TO ALEN(af,1) 制作成一个repl的宏表达式~
然后用 repl all &rpexp 表示~
看點資料吧
這是張洪舉書上的東西：關鍵在原理。VFP的數據庫處理速度快，主要是它能夠使用Rushmore技術，但這種技術是基於索引的，如果數據庫表本身沒有索引，則Rushmore技術就派不上用場。VFP的前身FoxPro原有的數據庫技術就比DBase快得多，那個時候還沒有Rushmore技術，可見對VFP來說，即使不用Rushmore技術，速度也不會慢到哪去。
Rushmore技術起作用時，使用的內存量大約是數據庫規模的三倍，如果它要快，必須把這些數據放置於內存中。一旦內存不足，必須在硬盤生成臨時文件時（被操作系統分配到虛擬內存），速度的瓶頸就是硬盤的讀寫速度。因此，除非保證可用內存的大小在被處理數據表規模的3～4倍以上，否則應考慮迴避使用Rushmore技術。
FP類處理數據庫，是一整條記錄讀進內存的，因此佔用內存的主要因素是單筆記錄的字節數，字段越多、每個字段的長度都較長，這個字節數就越多，它不管你實際要處理的僅僅是眾多字段之中最短的那一個。而用Rushmore技術，一次就處理整個數據庫！看看操作邏輯就知道怎麽回事：每讀一條記錄，僅有這條記錄的有限大小的數據放在內存（FoxPro有緩衝、預讀技術，先不管它，它總不會笨到把整個大容量數據庫都讀進來），對這條記錄進行掃描，就是在內存中的，字段再多，無論如何也不會太慢，這樣一次處理完一條記錄，確保不會再做讀寫操作；而若用REPLACE FOR指令，它是讀一條記錄進來之後僅處理其中一個字段，然後再處理下一條記錄，依次把整個數據庫都讀一遍，這個過程重複字段數那麽多次，此時，除非FoxPro的緩衝技術足以把整個數據庫全置於內存中，否則反復讀寫硬盤就是不可避免的。因此，數據處理的邏輯應是先橫後豎，而不要先豎後橫。
在C/S架構，客戶端使用SQL命令激發Rushmore技術，佔用內存的工作就在服務器上運行，雖然服務器的內存通常足夠，但問題是最終結果數據要通過網絡返回客戶端，如果最終結果數據量大，那麽網絡傳遞數據的時間就長。100M的內網，對4M左右的數據庫進行SQL查詢，測試速度在10～20秒之間。如果多臺客戶端都靠這種語句進行查詢處理數據庫，效果可想而知。
因此，對大容量數據庫處理，除非用SQL語句中的TOP選項，僅返回必要的記錄數，否則不要輕易啓動它。
SQL指令還有一點是讓人很不放心的：就是一旦出現錯誤，很難排查到底是數據庫中哪一條記錄導致問題。誰能保證數據庫中每筆記錄的來源都是符合規範的？特別是人機交互輸入數據的表，天才知道聰明的人類會通過什麽手段輸入各種不合法的數據到數據庫中，測試一百筆記錄成功並不等於實際運行時就可以高枕無憂，等到你發現測試沒問題但實操有問題時，就知道可糾錯的程序代碼的價値在哪裡。
這篇文章不妨參考一下：http://www.
[ 本帖最后由 TonyDeng 于 2011-7-3 14:29 编辑 ]
