創建前端MDE

Question

我創建了一個用於跟蹤度量標準的數據庫，其中包含一些自動化技巧（email，.doc，.ppt演示文稿等）以及大量的主表和GUI。這是我第一次擔心MDE /前端的問題。所以，如果你會回答幾個問題，或者提供任何建議，我會非常感激（我討厭所有這些工作都不被利用）。

• 我需要做的第一件事是什麼？它的2000版本必須轉換爲03才能創建MDE，但是在使用數據庫拆分器之前完成了嗎？

• 數據庫中的對象數量會影響執行此操作的能力嗎？我有80種形式，70種查詢，20種以上的宏，12種表格等等，但是一旦前端在那裏，對象的數量是否會妨礙某些工作正常運行？

• 當我拆分數據庫時，是否可以繼續在「後端」上工作/進行更改等，並且這些更改會直接影響前端？

這些可能是一些基本的問題，但我不知道答案所以.....謝謝！

Answer 1

這是我的2¢。

問題1 - 我從來沒有使用數據庫分離器，因爲我覺得我有更多的手動控制。如果您手動執行此操作，則可以將其轉換爲沒有數據庫分離器的版本。但是，如果您確實使用了分離器，那麼 - 在使用之前，您必須升級到具有分離器的版本。

手動這樣做是步驟。

1. 備份一切。
2. 將您的文件的副本創建到同一個目錄中。因此，如果您有一個MyApp.MDB，使用一個新名稱（如MyAppDATA.mdb）將副本創建到同一目錄中。
3. 打開新的DATA文件（MyAppDATA.mdb）並刪除除TABLES之外的所有對象。
4. 打開應用程序文件（MyApp.mdb）並刪除所有表格。
5. 也在MyApp.mdb中...轉到文件/獲取外部數據/鏈接表菜單，將MyAppDATA.mdb中的錶鏈接到MyApp.mdb。選擇全部並創建鏈接。

應該這樣做。如果你搞砸了，你做了一個備份......對吧？

一些技巧和疑難解答...確保你去工具/選項，你不顯示系統和隱藏表。你只是不想從MyApp中刪除系統表。另一種方法是不要刪除以MSys或USys開頭的表格。

問題2 - 無論你有多少物體。事實上，你無論如何都沒有那麼多的物體。

問題3 - 是的......您將在MyAppData.mdb中進行後端更改，並且當您打開MyApp.mdb時，這些更改將自動奇蹟般地在那裏查看和查詢等等（在查詢設計器中，您可能需要保存/關閉/重新打開，以查看新的字段，如果您在查詢中進行了修改）。 EXCEPTION是新表您必須使用文件/獲取外部數據/鏈接表選項來創建到新表的鏈接。

需要記住的一件事（而且我希望你已經意識到）是分裂數據庫的一個缺點是，當你部署前端文件時，通常數據的相對路徑會因機器而異，訪問中沒有自動重新鏈接表。如果您的目標客戶端具有完全訪問權限，您可以隨時使用工具/數據庫實用程序/鏈接表管理器來刷新鏈接到正確的位置。如果你不能這樣做，那麼你將不得不執行以下任一操作：
1.編寫自動重新鏈接代碼。基本上它會檢查鏈接...如果無效，它將提示用戶輸入數據位置（或在INI文件中查找）並重新鏈接表格。
2.始終將您的應用程序部署到所有機器上的相同位置。如果您有針對您的應用程序的商業願景，這將無法正常工作......我提到它是出於學術原因。對於有限的部署，您可以對每臺計算機上的文件位置進行很多控制。
3.將數據文件（MyAppDATA.mdb）放入網絡共享中，並使用驅動器映射或UNC（\ myserver \ mydata \ ApplicationData \ MyAppData.mdb）通過網絡鏈接表。後者是首選，但他們都有與第二個相同的風險。

賽斯

PS這個答案假定Access 2003中
PPS如果你有商業願景爲您的應用則該表的連接一定是真正穩健的。 PPPS我同意這位評論者的意見，如果你的技能集合是你可能想冒險嘗試的話。

Answer 2

這將是對Seth的回答評論，但我的代表還不夠高評論呢。

Seth在回答你的問題方面做得很好，我只是想在第一部分中增加一點關於使用數據庫分離器的內容。工具菜單中的數據庫分配器工作正常。手動操作也可以，但使用數據庫分配器的速度更快，更容易。我已經使用了十幾次，在使用它之後從未遇到任何問題。

http://www.databasedev.co.uk/split_a_database.html有一個體面的網頁關於一些優點，利弊分裂你的數據庫。

http://www.accessmvp.com/TWickerath/articles/multiuser.htm在處理多用戶環境中的拆分數據庫時也有一些很好的信息。

Answer 3

塞思給了你一個很好的答案。但我會添加一些評論。

只有當您接近約1000個具有代碼的表單，報表和模塊時，對象的數量纔會變得相關。這裏有一個限制。如果你得到時，試圖使一個MDE，那麼你幾乎可以肯定有一個代碼錯誤，需要編譯查找錯誤

另一個資源該消息爲「Splitting your app into a front end and back end Tips」

見Auto FE Updater downloads頁，使這一進程發佈新的FE相對無痛。該實用程序還支持終端服務器/思傑非常好。

Answer 4

有一件事沒有被討論過，這就是編譯爲MDE是否會失敗的問題。基本上，如果您的代碼在您的前端MDB中編譯，它將轉換爲MDE。但我注意到很多人從不編譯。

一些提示保持你的VBA代碼在良好的狀態：

1. 在VBE選項

   ，關閉COMPILE ON DEMAND。

2. 將COMPILE按鈕添加到您的標準VBE工具欄和USE IT OFTEN。定期備份您的MDB並反編譯/重新編譯它。

此外，請記住，你必須保持MDB源，因爲VBA代碼不是在MDE編輯，而不是由任何好的方法恢復。

編輯：

步驟的反編譯：

1. 備份您的MDB。

2. 使用/ decompile命令行參數啓動Access實例。對於，例如，我有我的deskstop快捷方式，有這個作爲目標：

   「C：\ Program Files文件\的Microsoft Office \ OFFICE11 \ MSACCESS.EXE」/編譯

3. 已經打開的那個實例訪問，打開你想要反編譯的MDB。你將看不到任何事情發生。在這個訪問實例中還沒有進一步的說明 - 關閉這個Access實例（原因是Michael Kaplan，誰知道這件事情，建議你不要在用反編譯開關打開的Access實例中做任何工作因爲他表示無法保證Access應用程序代碼在這些情況下以對各種Access工作完全安全的方式執行）。

4. 打開剛剛反編譯的MDB，按住shift鍵（您希望確保啓動例程不會運行，因爲在完成清理之前可能會重新編譯該產品），並壓縮MDB（持有再次按下shift鍵）。

5. 打開代碼編輯器並編譯項目（DEBUG - > COMPILE [db name]，這是在編輯之前的原始編譯指令中沒有第2步的人）。

6. 緊湊的MDB（如果你繞過啓動，因爲它已經完全編譯並不重要）。

爲什麼這麼多步驟？

因爲反編譯的目的是擺脫編譯後的p代碼，以便從規範的VBA代碼重新開始。按照上述步驟確保您在重新編譯之前完全清除了存儲已編譯代碼的數據頁。原因在於，在反編譯之後如果沒有緊湊的步驟，在某些非常罕見的情況下，代碼可能會表現得很奇怪。我無法想象舊的被丟棄的p代碼被再次使用，但是有一些關於規範代碼和編譯代碼之間的指針，顯然沒有緊湊的反編譯就不會完全被刷新。