VFP 愛用者社區

志明 · 註冊時間: 2003-10-27 文章: 30 第 1 樓

我現任的公司用 informix sql , 以前的 mis 則用 vb 、和 access 寫報表，速度慢，問題又一大堆。在沒有交接的形下維護，真的是百般無耐。很想建議公司放棄 dbms , 回到 dbf 或 dbc 。記得從前用 clipper 在 386 機器上跑(最大 dbf 有 50 萬筆)，比現在 p4快上千百倍。(我個人現處的環境，最大 table 2 萬多)

請問有沒有人，用 dbc 處理十萬筆以上的資料？

elleryq · 註冊時間: 2007-06-21 文章: 768 第 2 樓

作出適當的規劃,替換步驟與提案給老闆看看
如果合理的話,他應該會接受吧~

syntech · 發表於: 星期五十二月 05, 2003 3:48 pm 文章主題:

OLD USER 的通病嗎? 老是想回到table 時代 Smile

系統的規劃才是關鍵吧,應該不是table 還是 sql 的問題,
當然從dos 到現在 windows ,效能並不是線性成長,
所以才會覺得效果不顯著

Ruey · 發表於: 星期五十二月 05, 2003 7:30 pm 文章主題:

已經買了informix sql ,最好是繼續進行下去.
不要去想到以前的DBC架構了.

我沒用過informix sql,但我覺得它應該不比MS SQL差的.
尤其是在多人連線應用方面,優點會凸顯出來的.

志明 · 註冊時間: 2003-10-27 文章: 30 第 5 樓

OLD USER 的通病嗎? 老是想回到table 時代
系統的規劃才是關鍵吧,應該不是table 還是 sql 的問題,
當然從dos 到現在 windows ,效能並不是線性成長,
所以才會覺得效果不顯著

new user 沒有看過高效能的處理，所以無從比較。
就如我提到的，從前用486 dx66 當 file server ，client 端是386，流覽一對多的資料，
完全不用等待。現在 RS6000 和 p4 2.4G 還是覺得鈍鈍的。而且從前的明細檔是現在的 25 倍。我種情形叫我怎能不懷念過去。我個人認為，在區網沒有必要用 sql。

天文 · 註冊時間: 2003-12-11 文章: 6 第 6 樓

志明 · 註冊時間: 2003-10-27 文章: 30 第 7 樓

天文 · 註冊時間: 2003-12-11 文章: 6 第 8 樓

ruby · 註冊時間: 2003-06-03 文章: 25 第 9 樓

我們公司使用電腦人數將近150人,資料庫有用SQL及VFP,各有利幣,SQL在遠端連線處理較好用,但即時性不好,資料查詢下載大量時,主機負荷量過大,不適合多人使用,USER查資料僅能查下載當時資料,須一直更新才能查看新資料,但資料庫幾乎沒有損壞過,VFP無法遠端處理,分公司只有用PCANYWHERE作連線處理,只適用區網,資料即時可看,USER較習慣,IN,OUT資料非常多的TABLE較容易損毀,這類的資料記錄大約多在50萬至100多萬筆,最大的資料庫有到200多萬筆,1個DBC有掛上100多個TABLE,總TABLE有200多個,2種資料庫,在我這種後面接手的人來說,SQL比較好管理,因很少損壞過,但也因沒有什麼經驗,會害怕SQL這邊損毀,無法挽救,VFP有些常用的TABLE較容易損毀,因接手後資料庫的結構有整理一份,所以損毀後的修復到目前尚無問題,只是前人當初並沒有妥善的系統規劃,整個DBC,TABLE很亂,程式也寫的很死,修改及維護很辛苦,還有寫程式時要注意若查詢的TABLE,未來資料會有10萬比以上,最好不要用SELECT語法,若無可必免一定要用時,在語法前加SET TALK ON,語法後加SET TALK OFF,讓USER不要覺得電腦當掉.總之我覺得系統規劃完善,會比用什麼資料庫更重要.

天文 · 註冊時間: 2003-12-11 文章: 6 第 10 樓

幸好以前幫我們公司編寫這系統時規劃得很好，工程部 + 採購部 + 貨倉部 + 會計部四個部門，也只是用了二十一個 Table 來完成，而且速度很快，只是比Clipper 慢了少許，我真是很幸運遇上了這出色的程式工程師，令我學習了很多技巧。

志明 · 註冊時間: 2003-10-27 文章: 30 第 11 樓

感謝天文、ruby 的回應。
我決定建議公司改用 dbc 的架構。因為我公司目前雖有上百部電腦，但用 erp 的不到 30 部，4年的出貨明細才 2 萬多筆，實在沒有必要用 sql 。
請問 ruby table 損毀如何修復？有沒有發生過 dbc 壞掉？
很羨慕天文遇到好的工作環境，而我總是孤軍奮戰在收爛攤子，寫程式賣了錢卻拿沒到錢(被公司ㄠ了)。當了兩年的工人，現在回到這個職場，又是一個超級爛子。(我一個人要重寫鼎新的 tip top)
Sad

Erwin · 發表於: 星期四十二月 18, 2003 9:41 am 文章主題:

vfp有附一個gendbc.prg可以備dbc(也可以自己copy 檔案備份)
table損壞的話, 這邊應該找的到修復工具

elleryq · 註冊時間: 2007-06-21 文章: 768 第 13 樓

換個方向來想想
這是一個很好的歷練與挑戰啊

老是想到收爛攤子
心情會變差喔~
Smile

syntech · 發表於: 星期五十二月 19, 2003 9:28 am 文章主題:

TABLE 損壞其實不見得查的出來,站上或是其他我找得到的商業TABLE修復工具,
似乎都是針對檔頭損壞或是長度不正確刪除最末表,
但是若是TABLE內容出問題,例如HDD某個磁區出問題,
TABLE內容一部分變亂碼,則查不出來,我們公司就遇到一次(CLIPPER 5.3),
程式查不出原因,到現場比對才發現是TABLE內容出錯,
之後針對同一問題檢查VFP系統,發現同樣問題VFP亦查不出來

syntech · 發表於: 星期五十二月 19, 2003 9:43 am 文章主題:

我們公司的經驗(CLIPPER 15年,VFP 7年),的確,VFP較CLIPPER容易發生索引檔損壞的情況,
但是有一點必須說明,不見得是VFP的錯,可能是WINDOWS 網路通訊的問題,
走IPX的NOVELL NETWARE似乎比WINDOWS 穩定,
至於單走IPX的WINDOWS網路,會不會一樣穩定,
我不清楚,沒有足夠的SAMPLE佐證.
若同是單機情況,則都沒遇過索引檔損壞.

索引檔損壞,其實算是小事,偵測及修復都可以程式處理,使用者不見得查覺的出來,
設計上也不複雜.

就搜尋速度而言,資料量小時,VFP > CLIPPER > SQL,
但是資料量達一定程度之後, SQL的優點才開始出現,