2014-09-23 101 views
0

我有一個前段分割的ACCDB,其中包含許多帶有子表格(基於表格)和BE中的兩百多個表格(幾乎所有車輛對象都是小型查詢表格)和400多個查詢。也有碰巧存在另一個ACCDB與一個單一的表格與6.5M行,FE鏈接到基本的歷史信息。兩個後端不以任何方式相互鏈接。 FE爲14MB,BE爲1.2G,單表DB爲900MB,所有主鍵和索引都適當設置。數據庫100%正常化。 BE每個月都增長5%。該數據庫目前預計將在今年晚些時候遷移到Oracle 11G環境。拆分MS Access數據庫需要緊湊/修復以及前端和後端重新鏈接,爲什麼?

問題: 最近我發現如果我壓縮並修復後端或前端,沒有任何包含子窗體的窗體打開;整個有限元剛剛凍結成白色。即使所有3修復我仍然有問題。但如果我緊湊/修復所有3 以及將整個前端重新連接到兩個後端,所有突然開始工作的形式。直到最近纔開始這種行爲。

爲什麼我必須重新鏈接才能使表單再次工作?

回答

0

您正在將Access作爲數據庫的「無障礙」可行性(而不是「已記錄」)限制爲可行。記住需要編譯查詢,這意味着解析所有錶鏈接,並驗證現有的索引和其他元數據。有可能通過手動使用鏈接表管理器來覆蓋這些信息,這可能會更有效。

下面的幾個規定的技巧,這可能會幫助你: http://office.microsoft.com/en-gb/access-help/improve-performance-of-an-access-database-HP005187453.aspx

而一些更多... http://www.fmsinc.com/MicrosoftAccess/Performance.html#Linked%20Tables

和相關的從這個網站主題: Proper way to program a Microsoft Access Backend Database in a Multiuser Environment

問題,他們可能不是在幫你:

  • 個查詢不充分限制數據集,特別是那些運行動態集
  • 備份數據庫文件在Windows文件夾結構(越高越好)

由於第二連桿表明,真相坐在太低是否有這麼多的變量在工作,解決這個問題需要一些修補,試驗&錯誤發揮重要作用。

所有這一切,也可以升遷到SQL Server Express :) http://office.microsoft.com/en-gb/access-help/move-access-data-to-a-sql-server-database-by-using-the-upsizing-wizard-HA010275537.aspx

+0

但是您的帖子地址或EVEN都沒有提到爲什麼C + R會阻止應用程序工作?爲什麼在C + R之後需要重新鏈接?海報聲明應用程序RUNS JUST FINE AFTER重新鏈接。所以儘管你的鏈接對於娛樂和遊戲都很有用,並且可能指向一些好的做法,但沒有任何問題能解決問題和問題。 – 2014-09-23 20:39:26

+1

感謝大家,這是非常棒的信息 - 儘管答案將深深隱藏在Access的基礎之中我認爲最好的做法是將這個東西按照您的建議或Oracle(如就是我們在這裏使用的)。我感謝所有的幫助!當我從所提供的鏈接中找到某些東西時,我一定會更新這篇文章! – Fattire 2014-09-23 22:45:46

+0

@ AlbertD.Kallal--實際上,在我的回答中,我確實提出了一個關於行爲原因的建議,但是(現在已經證明這是無關緊要的假設證明了這一點),它實際上是一種猜謎遊戲,除非你真的可以嘗試一些已知的技術,其中沒有一個可以通過幾次點擊來實現 - 這是鏈接進來的地方。謝謝你的建設性意見,但是:) – Tim 2014-09-24 03:13:40

2

你不應該有一個C + R後,在所有在這裏重新鏈接任何東西。

唯一想到的是正在做C + R的用戶在C + R發生的文件夾或目錄中有一些受限制的權限。請記住,當用戶執行C + R時,會創建該文件的副本 - 因此可能會在創建NEW文件時繼承CURRENT用戶的權限。所以這聽起來像是文件夾中存在一些權限問題,或者正在執行C + R的用戶有一些特殊(不同)權限。 (也許某些安全組的成員身份有一些繼承權利)。

當然應該確保您使用的是UNC路徑名,當然還需要在每臺機器上放置前端。

也許再次使用C + R的用戶具有「不同的」驅動器映射,因此到後端數據庫的鏈接因此由於不同的驅動器盤符而錯誤。所以,如果還沒有,一般情況下我會盡量避免使用驅動器盤符,並使用NC路徑名(如果您還沒有的話)。

如果您使用的是UNC路徑名,那麼可能的問題是權限。

另一種可能性是,執行C + R的新用戶正在從「非」受信任位置運行前端。

此外,650萬行的表看起來有點大,我假設1.2演出的大小在C + R後是正確的? (但這個問題是針對另一篇文章的)。

這表明驅動器映射問題,權限問題,或者用戶啓動應用程序可能會引用引用。我將轉移到應用程序中,並確保執行C + R的用戶可以編譯該應用程序,並且可以從VBA編輯器中獲取CAREFUL注意到,例如,辦公室14的引用不會被辦公室15引用。

+0

艾伯特,Ty爲您的輸入。映射是通過UNC完成的......迄今爲止非常好。權限是好的,我也擁有管理權限。我最近沒有看過我的參考資料,但我通常使用的庫較新。如果存在的話,我會尋找更好的參考和實施。 650萬行是900MB,其實非常快。 1.2G很少超過1.5G,1.2G在C + R之後,但很少上升或下降,但數據庫每月增長大約5%就像我在下面回答的,一旦找到答案,我會更新。 – Fattire 2014-09-23 23:06:52

相關問題