用DELPHI2006 ADO 和MSSQL2000做的程式，使用REPORT BUILDER做REPORT，在預覽的時候非常緩慢（一般來說200PAGES要几分鍾才能計算完），請各位大大指示一下如何設置才能避免這種問題，謝謝！

200PAGES要几分鍾才能計算完
==>200頁用數分鐘的時間可能是久了點，但也可能是合理的。此時只能Show個進度作個交代了。
==>不管你是用那種ReportTool
==>如果你的報表生成時會有很多要到資料庫中作覆雜的讀取會寫入，那時間是少不了的，數分鐘有時難免
==>如果純是顯示，那就有點問題了。沒看到Code，不知道。

------
Kevin

請盡量避免在報表上做太扵複雜的運算，這樣會影響速度的。

謝謝二位，問題已解決，謝謝！

趕快結案吧。得分就選缺席就好。

------
Kevin

===================引 用 kevin2004 文 章===================
趕快結案吧。得分就選缺席就好。

我也想，但是我點“將此問題結案”沒反應呀

按鈕左邊有個ComboBox,指定得分者,再按下按鈕便能結案

小弟無功受祿，心下難安。貼幾句個人這幾天對這個問題的思考所得，請各位指正：
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

編輯記錄

如果200頁報表是重要報表，那你就非要搞點花樣騙騙客戶了。
以Web為例，在將整個網頁的東東全抓來Client端之前，不管是抓一些就Show一些﹝騙客戶好像是快了點，但實際是更慢了﹞，或是進程顯示，或是玩真的用AJax，都可以。
總之，要讓客戶付錢最重要。

------
Kevin