2012-08-10 73 views
2

隨着時間的推移,我的表格變得越來越慢。起初,在記錄之間導航幾乎沒有花時間。過了一會兒,它花了一秒鐘。過了一會兒,切換記錄花了兩秒鐘。現在我在三秒鐘切換記錄。提高子表格的速度

下面是詳細信息:

用戶得到提示,有一些選項可供選擇的形式。根據這些選項,主窗體彈出,只顯示相關記錄。主窗體鏈接到由用戶選擇生成的查詢。在主窗體上是直接鏈接到另一個表的子窗體(QuoteRunResults)。該表現在包含354,000條記錄。 緩慢的形式是子表格

下面是一個簡單的查詢,可以使用:

SELECT * 
FROM QUOTERun 
WHERE QuoteNumber = {UserSelectedQN} 
ORDER BY RunID DESC 

反正我有可以加快子形式?

+0

您已經壓縮並修復了後端數據庫,前端數據庫,反編譯了前端,並確保您有適當的索引,yesno? – Fionnuala 2012-08-10 14:43:02

+0

是的,我已經完成了所有這些。這是每週進行的定期維護,以確保一切順利。這可能是子表格正在處理兩個數據?每次更改記錄時,表單是否會返回到包含354,000條記錄的表格? – 2012-08-10 14:46:15

+0

如果它必須獲得新記錄,那麼它會回到表格中,但是如果表格可以利用索引,它應該很快。 – Fionnuala 2012-08-10 14:51:27

回答

2

我以前經歷過這種情況。我做了什麼來完全消除滯後是:

  • 使用查詢來生成兩個表單所需的兩個數據集。
  • Programically創建臨時表中的每個數據集,並從 填充它查詢
  • 鏈接的形式,臨時表
  • 的結果允許用戶做任何他們需要做的數據
  • 一旦形式programically關閉從 臨時表更新真實的數據
  • 刪除臨時表

這實際上所做的形式飛。我沒有更多的滯後問題。當我點擊按鈕移動到下一個記錄時,它立即發生。在我的情況下,我在OnTime事件中發生了很多事情,導致表單減慢。一旦我應用了上述,就馬上加快了速度。

+1

您是否認真建議將300K記錄複製到用戶的桌面?如果所需的選擇小於該問題可以通過使用明確定義的索引進行查詢來解決,無論如何。 – Fionnuala 2012-08-10 15:19:52

+0

不,我建議運行查詢來獲取用戶需要處理的記錄。然後將這些記錄複製到一個臨時表中使用。索引在我的情況下有所幫助,但不如我的建議。 – 2012-08-11 00:48:58

+0

我確實嘗試了你的建議,它確實提高了速度。其實我很驚訝。我必須弄清楚如何鎖定正在處理的記錄,並在表單關閉後進行更新。我弄明白了,現在一切都很順利。 – 2012-08-15 04:04:35