习惯说下载，应该是说从SQL2000中查询数据到本地表，然后，修改，然后保存到SQL2000上去。

下载是什么意思

已經是本地表，跟服務器上的源表是不同的物理實體，那是從外部文件向源表update數據的過程，與你編輯本地表的方式無關。實際上，你的本地表是獨占的，編輯它不需要什麽共享機制。

readwrite的cursor是複製出來的臨時表，編輯了它也需要灌入源表，不是直接編輯源數據。向數據庫灌入數據由數據庫自己管理，尤其是sql server之類。你用sql 語法的update做就是了，具體怎麽執行，sql語法隱藏真實動作的，我們無從得知。

我再强調一次：在vfp中挂入sql server不是在使用vfp數據庫！此時vfp僅僅是如vb、C等一樣是界面工具，VFP的數據庫特長和機制喪失。

[此贴子已经被作者于2016-3-17 14:44编辑过]

我明天T版的意思，像我这样的情况，我修改数据后，只能1条条来更新到SQL上去了。

原理的東西，說起來都很簡單，都不屑問不屑深究，還嫌說的人淺薄，說自己懂的東西，但但實際上，往往就是原理不過關造成的問題。a=b，a不是b，其實就是這個道理，都懂，但是呢…怎麽改b跟怎麼改a就是兩回事！

查詢出100條記錄的視圖，編輯了其中20條，用SQL UPDATE FROM灌入源數據庫，這裏我們就無從得知數據庫的真實行爲。把100條記錄覆蓋了？有無挑選？是覆蓋還是把原來的刪了再追加？若有where不匹配的記錄怎麽辦(改了關鍵字段的數據)？我從來不放心這類不知道處理機制的語句。SQL Server等數據庫正是無法掌控單條記錄的。

[此贴子已经被作者于2016-3-17 15:49编辑过]

那他们说，用视图来更新SQL数据，是什么回事。
我为什么要问这个，是因为，我用SCAN...来1条条更新，如果网络慢的时候，可能要等待十几到几十秒，或者更多。
所以我想知道，你们这些高手，是怎么处理这样的事情的。

慢是恰好處於共享并發時間段，踏入這個時刻，用什麽方法都一樣慢。整個表鎖定可以稍微加快，但對別人來説你鎖表等於他等待時間長，此時會出現搶先鎖定，不斷短時間内嘗試鎖表，增加網絡負擔，更慢。在網絡帶寬不是無限的情況下，這是無解的，必須規劃訪問規則，換言之，有限的解決辦法是設計的系統避免多用戶同時編輯同類内容，以降低衝突機會。

共享數據從來不是簡單的問題，沒有靠什麽先進數據庫就可以解決的，設計不好，都是白搭。

多記錄鎖定機制是會降低整體速度的，因爲那個用戶都要把自己試圖鎖定的一批記錄查詢一下別人鎖過沒有，哪怕僅是其中一條被別人鎖了，你的整個鎖定動作就失敗。記錄鎖得越多，越容易出現失敗情形，於是大家都是不斷嘗試加鎖，時間都耗在這裏而不是做正事。