REPORT BUILDER預覽緩慢的問題 |
答題得分者是:kevin2004
|
bayman
一般會員 發表:30 回覆:35 積分:18 註冊:2007-04-24 發送簡訊給我 |
|
kevin2004
資深會員 發表:18 回覆:463 積分:416 註冊:2005-05-29 發送簡訊給我 |
|
bruce
中階會員 發表:19 回覆:121 積分:83 註冊:2002-04-16 發送簡訊給我 |
|
bayman
一般會員 發表:30 回覆:35 積分:18 註冊:2007-04-24 發送簡訊給我 |
|
kevin2004
資深會員 發表:18 回覆:463 積分:416 註冊:2005-05-29 發送簡訊給我 |
|
bayman
一般會員 發表:30 回覆:35 積分:18 註冊:2007-04-24 發送簡訊給我 |
|
taishyang
站務副站長 發表:377 回覆:5490 積分:4563 註冊:2002-10-08 發送簡訊給我 |
|
kevin2004
資深會員 發表:18 回覆:463 積分:416 註冊:2005-05-29 發送簡訊給我 |
小弟無功受祿,心下難安。貼幾句個人這幾天對這個問題的思考所得,請各位指正:
1.小弟只用過QuickReport及FastReport。QuickReport是公司裏早年的主力,小弟當初也負責劃了好幾百張報表,可是QR跟Delphi綁的太緊,先天架構就有點不良。一張報表佔了不少資源,即使設為動態建立,還是會有影響。當系統日趨肥大時,一個系統中這好幾百個QR報表對系統拖累不少,甚至會拖垮系統。再加上QuickReport對DataModule牽的太緊,QRForm上的元件對TField綁的太死,不如FastReport的靈活好用及經濟,及FR以SQL-String的超級現代的作法,其差別真不是可以道里計。 2.有些很Critical的系統在某些FastReport報表中為了監督何人列印及列印那些敏感資料,會在報表每筆印製時同時逐筆將印製人及列印的資料寫入DB中。這就無法省這個工了。 3.都是到DB準備資料,其處理在AP的速度通常會快於FastReport,所以如果有必須作很複雜的SQL與處理,就先在AP中處理好,再丟到DB裏,再用個簡單的SQL丟給 FastReport去抓現成的資料,再加上前處理時加個進程顯示騙User稍安勿燥,那User對速度的『感覺』就可以快很多了。 4.如果必須到Registry或INI對FastReport報表作一些不同客戶的不同處理,那這些處理有時可以先在AP作好及用變數傳給FastReport,那速度也會快一些。
------
Kevin |
kevin2004
資深會員 發表:18 回覆:463 積分:416 註冊:2005-05-29 發送簡訊給我 |
本站聲明 |
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。 2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。 3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇! |