其實還是看具體條件，查詢出來的臨時表如果能夠滿足動作的要求，是可以的，但如果不能滿足，就不可以，因此你覺得這是不穩定，但應該是不熟悉SQL指令都幹了些什麼的原因。事實上，你也看到我多次說過不是很瞭解SQL語句而避用，除非我測試過某種寫法真是可行的，才會用，否則，我寧願自己寫操作代碼達到目的，畢竟後者是自己可以自由操縱的。

“不穩定”的關鍵，應該是我2樓提到的，條件表達式有時候不是真正的變量表達式。一般命令（指的是諸如SELECT、REPLACE、INSERT、UPDATE等非函數形式的指令）中參數的傳遞，往往是用宏或動態運算，某些參數，看似是變量，但其實經宏替換之後可能是常數。

比如USE TableName，參數本來應該是字符串"TableName"，因為就是真的要打開這個表名，但命令形式寫出來，卻似乎是變量，在我們真需要是變量的時候，就必須寫USE &TableName或USE (TableName)。也就是說，像WHERE L1.A3=L2.A3這樣的，我們未必知道到了執行代碼內部，是L2.A3還是不是變量——測試的結果表明確實不是變量，而是當前L2記錄的字段值，可以先把L2的指針移動一下，比如GOTO 2，看看是不是更改了2這條記錄就知道了。有的時候，恰恰怎麼變都不影響結果，那就蒙對了。“不穩定”，應該是這樣來的。

SQL命令的機制，是針對內存中的記錄集合，而不是直接對數據庫文件，記錄集合是用查詢語句形成的。無論是簡單的SELECT查詢，還是有後續動作的UPDATE、DELETE，首先都用SELECT提取記錄集合，然後視是否有後續動作而做，對UPDATE則先批量處理查詢視圖數據，然後按照記錄下的路徑把結果反饋到原始數據庫中（這肯定是為了避免網絡遠程來回開銷而設置的離綫處理功能，為了儘快釋放記錄鎖不致拖慢多用戶訪問數據庫而設計的），對帶INTO參數的，就把結果輸出到指定地方。所以，關鍵之處是把所有需要處理的數據都與原始數據源分離，然後整合成處理需要的形式，再做動作。正是這種分離，使SET RELATION關聯失效，因為UPDATE實際做循環更新動作時，臨時視圖已經不再與原始數據源關聯了，此時即使用L2.A3來查尋數據，也只能是當前L2記錄的A3值（成為事實上的常數，我後來補充的函數，就是為了使這個值變起來），除非查詢時把L2的數據捆綁到L1中成為同一張表以供循環使用。

所以我一直說，如果不是訪問遠程數據，最好不要使用SQL指令，有太多我們不知道的小動作，何必為了一點小問題要翻遍厚厚的SQL指令手冊呢。背後裏做了那麼多動作，無論如何都不可能比本地直接操作文件的VFP內置數據庫指令高效的，那才是VFP的殺手鐧，否則，它跟VB無異，這門語言就失去存在價值了。事實上，時至今日，我對遠程數據的訪問，都很抗拒SQL指令，現在是用XML文件傳遞數據的，本地程序用VFP處理，服務器端用C#和ASP .NET，全都避免註冊服務，只要能夠通過網絡上傳和下載文件，就可以完成任務。（根據手頭的ASP .NET資料，微軟在.NET4框架中出現放棄Ling to SQL的苗頭，明確宣佈以後不再發佈相關支持產品，要繼續使用SQL的，由第三方開發。）


[ 本帖最后由 TonyDeng 于 2012-2-7 17:13 编辑 ]

panpende 老师提的问题,我个人觉得都是有点难度的不是随手能解释。过去我也碰到过这种事，所以，干脆，索引了的表不再用 SQL 语句，因为它里面有独立功能，把其他索引给费了。但是像 delete for，replace 语句等不要紧，他们和 INDEX 都出自于最初的 fox. 我的体会，记住实验出的结果最重要。


[ 本帖最后由 qingfameng 于 2012-2-7 23:25 编辑 ]

继续讨论UPDATE 。将程序段稍微变化一些。
SET TALK OFF
SET SAFETY OFF
SET CENTURY ON
SET EXACT ON
SET DATE YMD
CLEAR ALL
CLOSE DATABASES
CREATE DBF L1 (A1 C(10), A2 C(10),A3 N(4)) &&建立表
FOR X=1 TO 8
Y=STR(X,1)
APPEND BLANK
REPLACE A1 WITH 'SJA'+Y,A2 WITH 'SJB'+Y,A3 WITH X
ENDFOR
COPY TO L2 FOR A3<6
INDEX ON A1+A2 TAG A1
SELECT 0
USE L2
DELETE FOR A3=3
PACK
INDEX ON A1+A2 TAG A1
SELECT L1
SET RELATION TO A1+A2 INTO L2

UPDATE L1 SET L1.A3=L2.A3+10 WHERE L1.A1=L2.A1 .AND. L1.A2=L2.A2

BROWSE
RETURN

这段程序比较好的达到预想的目的，对L1 中符合要求的4个记录进行了替换。

我不知道为什么？

谢谢qingfameng老师关注，你在13楼的答复对我很有帮助。
确实 如 REPL FOR .... 以及 DELE FOR .... 等最初的 fox命令，运行起来正确性稳定性，我从来没有怀疑过。但是为了寻找优化、高速的语句不得不试用如 UPDATE SQL等命令。

回复 panpande 老师：我又仔细查了一下，发现上面我的回答有点草率，特此抱歉。实际上，按照语法，在两张表作关联时，L1 是不应该再作复合索引的，他是主关联的表。而被关联的表 L2，必须要索引。所以，把这个主关联表的索引去掉后，无论 SQL 语句还是不是，都可行得通，L2 表要独占打开。除此之外，你所列举得的所有程序代码都不要动。你可以再试试。主关联表做了索引，对 delete 语句有影响，甚至产生循环错误。
（仅作参考）


[ 本帖最后由 qingfameng 于 2012-2-9 02:38 编辑 ]

谢谢qingfameng老师，按你在16楼的指导，去除L1的索引，原例题达到了预想的目的。对二表关联的认识因此也进了一步。不知你是否注意我在14楼程序变动，在那里L1还是有索引的，但是例题是达到了预想的目的的。
现在看来二表关联，主表有没有索引，似乎无关紧要，应该对速度没有影响。不知能否肯定。
TonyDeng老师在11楼、12楼对SQL命令機制的解说，使我加深了对SQL命令的认识，以后将慎重应用SQL命令。十分感谢TonyDeng老师无私赐教。我将再提一个SQL问题，以求赐教。

回复 panpande 老师:您16楼的程序段我是看过的。那个主表 L1 的索引仍然是可以去掉的。因为语法中规定，不允许对他索引。索引了反而造成不稳定或出错，(当然不一定提示)。这些我也都试验过。如果不索引是否影响运行速度，我个人认为不能再做考虑了，他们微软公司的vfp开发者应该会注意这个问题。因为咱们这些人都想到了，他们能不想到吗？（不好意思，个人认为的）。再次谢谢您的鼓励！

万分感谢qingfameng老师的指教。我将在今后的编程工作中采纳你的意见。