VFP 愛用者社區

[crux]

為了效能的提昇，想說將開檔方式改成SQL SELECT * INTO CURSOR的方式。

雖然程式是在網路環境，但其實使用的是一般的TABLE，而非MS SQL的Table，所以跟使用LOCAL的資料環境類似。

載入時以SELECT INTO CURSOR的方式讀至暫存檔，顯示時抓取CURSOR的資料欄，只在資料更新時或新增刪除時，才回去存取變更原資料檔，以為會像ORACLE的資料庫，只在產生CURSOR時才讀取，一般瀏覽時僅引用CURSOR的暫存資料，想說這樣不會佔用頻寬，即使掛在網路上不存取時，應該不會開到檔案。

但是程式幾乎快寫完了，放到SERVER上監看開啟的檔案，才發現即使SELECT * INTO CURSOR的語法，未使用任何USE TABLE的語法，它仍然還是偷偷地開了TABLE，必須在UNLOAD時，自己寫程式關閉資料檔，這讓我有點騎虎難下了，為何SELECT * INTO CURSOR也會開檔呢?

跟傳統直接USE的方式，SELECT * INTO CURSOR是否真能提昇效能?
還是說除非使用真正的SQL Table，若屬於LOCAL的TABLE(DBF)根本不需這麼做?! 用傳統USE的模式即可?!

有高人對此有所鑽研的麼? 期待有人能夠解答....

[syntech]

看沒有?

如果你沒有把CURSOR 關掉 (USE),而保持CURSOR 開著,
是保持SELECT 的來源,沒錯.
這與 VFP 產生這種CURSOR的方式有關.

實際上,m$ sql 的server 端cursor,
我記得好像也是由sql server 開著這個檔案,達成live cursor的情況.
當然在vfp上,這就變成你的程式在背景偷偷做的事.

SELECT * INTO CURSOR 能否提昇效能,
也與VFP產生CURSOR的方式有關.
是會比SELECT * INTO TABLE 快,
但是好像不會比直接USE 快.

因為vfp 有時是以 filter 方式做一個假的cursor,
有時是產生一個dbf 格式的 in-memory table,
有時這個in-memory table 也會產生到hdd中,變成一個實體檔案.

總之,我覺得你好像沒搞清楚 VFP是怎麼產生SELECT - CURSOR 的.
卻把其他工具的CURSOR觀念拿來套

[crux]

感謝你的解答^^

有點難解釋，基本上會動這個念頭，是在多人使用環境時，若有人閒置時，處在USE Table的狀態，雖然是Share的模式，但總覺得這樣會佔用頻寬，才想到使用CURSOR的觀念，將資料讀取至CURSOR，以GRID的方式讓使用者點選，即可切換資料錄，而不必一直開著原始資料檔，有點像Oracle只在需要資料時，才擷取必要的的欄位。

所以問題應該不是開檔的快慢，而是說以CURSOR暫存的觀念來處理檔案，是否對整體的網路效能較佳呢？

倒是SELECT * INTO CURSOR 的方式竟然在背景偷偷開檔，
SELECT * INTO CURSOR cTemp FROM XTable....
以上語法，同時也開啟了Xtable，這讓我蠻意外的，變成我想避免一直開著Table的情況，到最後仍然無法避免開著Table不放。

[richshih]

sele 後是可以USE來源檔的 但當UPDATE CURSOR 時他會再自己打開他
個人經驗應多使用 cursorsetprop() 來一次更新 避免時常與主機聯繫

[syntech]

"問題應該不是開檔的快慢，而是說以CURSOR暫存的觀念來處理檔案，是否對整體的網路效能較佳"

case by case

不過我覺得應該不會比較好.

如果是操作 dbf/dbc 的話,
實際上一樣會use 檔案,而 select 還會自己偷建index,偷建暫存檔,
如果遇到where 條件是會搞成table scan的情況,
反而會從檔案頭掃到檔案尾在建立cursor,
比直接use還糟.

之前站上有討論過 odbc 的vfp driver 怎麼作select 命令,
情況大概類似.

可能只有由sql server 抓回來的cursor 情況還好一點.
因為傳回的只有完整table的一部份(cursor),
如果採用的是 spt 的資料操作模式,
就可以真的切斷連線,等需要更新時再接回來.

資料庫之所以會由 file base 的 1-tier ,
演進到 client/server 的 2 -tier,
原因之一就在 file base 在網路分享時的傳輸量過大.