移植MS Access應用程序

Question

我的一位朋友請求我幫助他評估一些報價，用於將基於MS訪問和VBA的桌面應用程序移植到基於Web的應用程序。應用程序似乎有相對大量的業務邏輯編碼到VBA中。

我的問題是非常具體的 - 有沒有什麼好的工具或資源可以幫助從訪問移植，而不是做一個完整的重寫？

用於網絡應用程序的最終技術並不重要，但理想情況下儘可能成爲主流。

Answer 1

對於一些基本的東西，可能會有一些工具，比如升到不同的數據庫，或者可能是表單的外觀和文本框，但是轉換聽起來像很多VBA代碼，不太確定。

這是一個內部網/本地網絡類型的網絡應用程序，或者你是否把它放在網上？安全將成爲這個和你的訪問應用程序之間的主要區別。

確保他們瞭解Access/VBA，以便您可以維護Access應用程序生命週期中的業務邏輯。

說服你的朋友停止/減緩Access應用程序的任何開發，以防止公司瞄準移動目標。這可能不現實，但確實需要考慮。

Answer 2

您可以探索Sharepoint提供的可能性。它可以幫助你在線訪問數據，但是這項工作的好壞也取決於Access應用程序中使用了多少VBA代碼。

有一些工具假裝他們可以將MS Access轉換爲PHP/ASP網站，如DB Forms，但我沒有嘗試過，他們通常只轉換應用程序的可見部分而不是查詢和VBA。
雖然他們可以幫助開始。

隨想

的VBA往往是最大的問題。 移動到ASP.Net需要時間和要面臨艱難的抉擇：

1. 傳輸的所有代碼到ASP.NET只得到它的工作
2. 重新考慮結構和做一個適當的ASP。從頭開始實施。

我更喜歡第一個：只是儘可能努力才能快速獲得結果。
使用SSMA將數據移動到SQL Server（除非要保留​​Access作爲後端）。
使窗體看起來與您現有的應用程序（或至少具有相同的功能）相同，將VBA移植到VB.Net（或者如果您覺得它是C＃），則按窗體，模塊和模塊形式進行移植隨你走。

在這個階段不要嘗試重構或改善事情，關鍵是要在舊系統上「拍」舊代碼，並使它像過去一樣成爲樹皮，而不是更好，更糟糕。

只有這樣你才能開始重構和改進使用新的工具在您的處置。

我在說這一切都假設舊應用程序沒有任何可怕的錯誤，並且它只是需要移植到在線消費。

如果舊應用程序有缺陷並且沒有履行其職責，那麼應該更加重視重新考慮應該翻譯哪些部分以及應該重寫哪個部分。

無論如何，您需要制定詳細的行動計劃和對當前代碼和功能的審查，並儘量限制您對新系統第一版的期望：避免讓所有人輸入他們的意願否則你的項目將變得非常困難。

專注於達到某種程度的功能所需的最低限度，以滿足用戶的需求，然後在此基礎上進行構建。

Answer 3

是否有理由在Windows終端服務器上託管應用程序不能滿足要求？這意味着應用程序無需更改，無需重新編程成本，也不會丟失關鍵業務邏輯。如果您使用Citrix擴展，您可以在網絡瀏覽器中運行它（儘管我猜測它只適用於IE - 我從未使用它們）。但RDP客戶端的版本適用於Mac和Linux以及Windows，所以只要爲他們的操作系統安裝RDP客戶端，基本上可以支持任何人。

是的，它在客戶端更安裝，但它是一個helluva很便宜，更容易開發，並避免了失去重要的東西編碼到Access應用程序的問題。

當然，支持WTS/Citrix上的大量用戶羣可能會變得昂貴，如果Access應用程序需要重新設計，無論如何，它可以改變餘額。但這是你應該考慮的。它實際上是真的很容易設置WTS，並且爲它配置服務器基本上是添加RAM和互聯網帶寬的問題（儘管RDP開始時效率很高）。

一個關鍵的錯誤很多人試圖運行在WTS訪問應用程序時做：（前與形式/報告/等等，回來只有數據表結束）

必須拆分數據庫，每個用戶必須擁有自己的前端副本（存儲在WTS上的用戶配置文件中，或存儲在WTS服務器數據分區上的文件夾中，並且分配給授權使用該應用程序的用戶組的相應權限）。 Tony Toews's front-end updater在這種情況下非常有用，並且明確設計爲在終端服務器環境中工作。