我目前鏈接到六個Excel電子表格,主要是因爲用戶更容易/更好地編輯Excel中的數據(他們從未使用Access),並且任何更改都會立即反映出來,包括是否添加了新的列,然後立即爲查詢使用。導入與鏈接到Excel電子表格
但是,鏈接代替導入這些數據會有性能損失嗎?我的一些查詢很慢,1-2分鐘,有時可能需要2-3分鐘才能保存查詢。如何在每次打開數據庫時設置Access以導入新版本的這些表單,是否值得?
我目前鏈接到六個Excel電子表格,主要是因爲用戶更容易/更好地編輯Excel中的數據(他們從未使用Access),並且任何更改都會立即反映出來,包括是否添加了新的列,然後立即爲查詢使用。導入與鏈接到Excel電子表格
但是,鏈接代替導入這些數據會有性能損失嗎?我的一些查詢很慢,1-2分鐘,有時可能需要2-3分鐘才能保存查詢。如何在每次打開數據庫時設置Access以導入新版本的這些表單,是否值得?
有4個因素馬上想到的關於聯電子表格的性能:
鑑於保存查詢通常很慢,我的猜測是#1是您的主要瓶頸。是的,使用鏈接而不是導入會有小的性能下降,但是您的使用案例(小數據集,不是太多的鏈接)會使這個懲罰非常小。另一方面,緩慢的網絡會減慢每個操作的速度,包括將更改保存到Access數據庫本身。
我將所有文件複製到我的C盤上,並重置鏈接以使用C:版本的Excel文件,並且延遲仍然存在,所以我認爲它不是#1。我不認爲#2或#4是一個問題,但#3我傾向於建立多級別的查詢 - 即我會有一些基本查詢直接訪問鏈接表,然後幾個查詢引用到這些基本查詢,然後再引用這些第二級查詢的一些更復雜的查詢。這不是最佳做法嗎?鑑於查詢無法編入索引,這是否會出現放緩? – Wilskt
根據你剛剛在這裏所說的,#3 +你無法索引數據的事實是性能低下的明顯原因。 –
您可以通過ADODB連接連接到excel文件並在ADODB.recordset中打開它。速度非常快。事實上,它可以像連接到「真實」數據庫一樣快。
實現此類解決方案的可能性取決於您將查詢翻譯成記錄集的能力。您需要熟悉VBA和ADODB對象,因爲您必須編寫用於生成記錄集的代碼,然後在屏幕上(或報表中)顯示其內容。
在我的頭上和下面 - 也許在幾年內。 8-) – Wilskt
只有一個問題:您是否嘗試過使用Access中提供的嵌入式「從Excel導入」工具?數據正確導入和編制索引後,請嘗試查詢您的查詢。如果您看到有很大差異,那麼您可以考慮自動從Excel導入數據。這並不複雜,因爲您可以將VBA導入功能與文件多選框相結合。 –
我試圖在Access宏中使用transferspreadsheet和runsavedimportexport自動化,但是我遇到的問題是Access決定某些字段是整數,即使有進一步的文本值,以及它放置的字段數據已被設置爲文本。討厭,但不要以爲我能做些什麼,而不是在電子表格中放置一個虛擬的行,我真的不想這樣做。 – Wilskt
我把我結束了與解決方案,因爲它幾乎解決我上面有問題,包括自動地更新數據:
有適當的Access表與查詢,例如使用tblStoreDetails,tblPromotions
仍然使用電子表格來維護數據,因爲這是更新的最靈活的方式/觀看這些東西沒有建立形式/在接入前端,這不會真的是值得的時間爲NO-其他人將直接使用數據庫。
Access中的這些表的鏈接,例如, excelStoreDetails,excelPromotions
使用Delete查詢設置啓動時運行的Autoexec宏(假定單擊enable macros按鈕)以清空Access表,並執行Append查詢以將鏈接的Excel表中的行添加到訪問表。
這樣可以避免由於刪除/重新導入表而導致的問題,主要是它們都以未分配的對象組結束;或者嘗試使用導入規範並結束類型不匹配。
但是,我現在只是發現一些較大的表的缺點是鏈接電子表格中的追加查詢可能非常緩慢,並且磁盤上的數據庫大小現在很大。可能在閉鎖時考慮自動緊湊和修復,但這會增加更多時間。嘆氣,如果Access是一匹馬,現在有人會開槍。 – Wilskt
這不是一個很好的**多用戶**設置,你不希望用戶能夠修改結構,例如添加/刪除列。我不確定您的訪問背景/知識水平,但我傾向於將所有表格存儲在訪問中,併爲您的用戶開發前端屏幕以便與數據進行交互,這是您的選擇嗎? –
對於系統的大小及其使用方式,不值得開發前端屏幕。我認爲,如果我可以設置一個宏來在每次打開數據庫時導入電子表格,並鎖定電子表格,這樣只有我可以添加額外的列,這將是一個很好的平衡。 – Wilskt
但是,我是否通過鏈接到電子表格而不是將數據放在Access表中來降低性能? – Wilskt