請問我有一A.dbf與A.cdx,將某一text(40萬筆紀錄)轉入dbf中更新(有則修改,無則新增), 但是只能更新85922筆,之後就會出現Access to table disabled because of previous error的訊息,使得之後的資料都無法更新至dbf中, 我用的是infopower的TwwTable,請問應如何解決,這是因 1.索引檔壞掉:那應如何重建索引檔(以原A.cdx的結構重建)? 2.某種限制(記憶體等或元件本身的限制),只能更新85922筆? 3.其他? 另外我有THalcyonDataset元件,但若用此取代似乎轉入速度很慢,

引言: 請問我有一A.dbf與A.cdx,將某一text(40萬筆紀錄)轉入dbf中更新(有則修改,無則新增), 但是只能更新85922筆,之後就會出現Access to table disabled because of previous error的訊息,使得之後的資料都無法更新至dbf中, 我用的是infopower的TwwTable,請問應如何解決,這是因 1.索引檔壞掉:那應如何重建索引檔(以原A.cdx的結構重建)? 2.某種限制(記憶體等或元件本身的限制),只能更新85922筆? 3.其他? 另外我有THalcyonDataset元件,但若用此取代似乎轉入速度很慢,

1.Delphi 不支援 cdx 索引檔, 我不知道inforpower的 TwwTable 是否有支援 不過就我所知好像只有ApolloVCL6有支援多種索引結構 Delphi只能使用 mdx 2.要確定是否索引檔所造成的問題, 把 a.dbf 先用Delphi附的 Desktop系統 開啟同時選擇移除索引檔, 先直接以 dbf來異動, 8萬多筆應不致造成你遇到 的問題, 我想可能是索引檔在做怪! 3.建議你儘量用Delphi提供的標準元件, 或者是找有 sourcecode元件的 shareware, 目的是版本上的相容及支援性能比較高 4.索引檔重建, 建出來是dBaseV的 mdx索引檔 以上提供你參考!

引言: 2.要確定是否索引檔所造成的問題, 把 a.dbf 先用Delphi附的 Desktop系統 開啟同時選擇移除索引檔, 先直接以 dbf來異動, 8萬多筆應不致造成你遇到 的問題, 我想可能是索引檔在做怪!

1.抱歉,不明白你的意思,如何使用Desktop開啟並選擇移除索引檔,而直接以dbf 異動 2.請問我是不是應先以某工具重建Index,再做轉檔測試, 我目前有Desktop與Griffin Solution's DBF Desktop,如何使用? 3.A.dbf中有一些資料是被delet掉的,是否先做Pack,有無影響? 4.40萬筆文字檔(每筆3個欄位而已,不長)轉入,大約需多久?前一萬筆很快,後來越來越慢 5.此dbf檔的cdx有三個索引,是否先移除兩個,轉完後後再重建較快?

1.抱歉,不明白你的意思,如何使用Desktop開啟並選擇移除索引檔,而直接以dbf 異動 2.請問我是不是應先以某工具重建Index,再做轉檔測試, 我目前有Desktop與Griffin Solution's DBF Desktop,如何使用? 5.此dbf檔的cdx有三個索引,是否先移除兩個,轉完後後再重建較快? 一併回答, 先把該檔案的索引檔刪除, 再利用Delphi內提供的 DataBase Desktop 系統來開啟, 當你的dbf檔如果有加掛任何索引而對應不到時, 系統會偵測到同時在開檔同時詢問你是要以ReadOnly開啟, 或是Detach Index(移除索引), 你選擇本項, 就可以將index mark 由 dbf中移除, 這樣再開啟檔案就不會有問題 3.A.dbf中有一些資料是被delet掉的,是否先做Pack,有無影響? BDE雖然有提供 DBF 的 SOFTDELETE功能, 但基本上BDE被執行時是會忽略被DELETE的記錄, 當然如果你做過PACK, 不論是否DELETE存在, 經過PACK原則上是會重整調整資料庫, 所以在速度上來說會有些加快, 快多少? 無數據可查! 4.40萬筆文字檔(每筆3個欄位而已,不長)轉入,大約需多久?前一萬筆很快,後來越來越慢 這是正常的, 因為dbf都是在前端buffer直接運作, 異動越多, 可用buffer越少 也就是說每筆異動都會先被轉入buffer中運算才丟回database, 但丟回去後並不會清除buffer中所佔掉的空間, 如果你要解決這個方式, 只有一個方式, 關閉此檔, 重新開啟, 開啟時先處理掉已經異動的記錄, 這樣才能清除, 有些資料來源說利用refresh或dbisavechange就可以達成, 但我實測結果是沒有用! 你可以設計每一萬筆做一次, 之前我更新過約100萬筆就是這樣搞, 雖然還是慢 但絕對比一次過要省2倍以上(相較之下) 發表人 - P.D. 於 2004/01/12 00:32:03

這是正常的, 因為dbf都是在前端buffer直接運作, 異動越多, 可用buffer越少 也就是說每筆異動都會先被轉入buffer中運算才丟回database, 但丟回去後並不會清除buffer中所佔掉的空間, 如果你要解決這個方式, 只有一個方式, 關閉此檔, 重新開啟, 開啟時先處理掉已經異動的記錄, 這樣才能清除, 有些資料來源說利用refresh或dbisavechange就可以達成, 但我實測結果是沒有用! 你可以設計每一萬筆做一次, 之前我更新過約100萬筆就是這樣搞, 雖然還是慢 但絕對比一次過要省2倍以上(相較之下) 請問如何做:"開啟時先處理掉已經異動的記錄"?