小村軟體有限公司
日本語 English 한국어 繁體中文 简体中文 العربية
聯絡我們
選單

VB6 / Access 業務應用程式的延命與遷移 ── 保留・包裝・取代的判斷表

· · VB6, Access, VBA, 遺留資產, 既有資產活用·遷移, Windows 開發, 資料庫遷移, 現代化, 判斷表, 技術諮詢

「用 VB6 寫的核心系統一部分仍在運行」「用 Access 做的台帳，其實支撐著部門業務」──在中小企業的諮詢中，這兩種情況至今仍相當常見。共同點是，當初開發的人早已離職，或是沒有人能準確說明它為什麼還能運作。儘管如此，因為系統沒有故障，優先順序往往還是被往後排。

本部落格過去已經針對個別技術要素撰寫過「COM / ActiveX / OCX 是什麼」、「ActiveX / OCX 保留・包裝・取代判斷表」、「VBA 的限制與未來性」等文章。這次縮小範圍，針對日本中小企業至今仍廣泛留存的兩大遺留資產──VB6 應用程式與Microsoft Access 業務應用──整理「該直接保留」「只包裝一部分延命」還是「全面取代」的實務判斷指南。判斷架構沿用 ActiveX / OCX 文章中「保留・包裝・取代」的三選一，但對象不同、風險內容也不同，因此本文將以獨有的論點為中心整理。

1. 先講結論

  • VB6 的 IDE・開發環境本身，已於 2008 年 4 月正式終止支援。以正式手段進行新開發或改版的方法已不再提供。1
  • 另一方面，VB6 執行環境(msvbvm60.dll 等)只要搭載於仍在支援期內的 Windows，就屬於運作對象。「既有 VB6 應用程式在對應的 Windows 上大致能持續運作」這個前提至今仍成立，但這完全取決於 Windows 端的支援期限。1
  • VB6 僅支援 32bit，無法進行 64bit 原生編譯。在 64bit OS 上，是在 WOW64 這個 32bit 相容環境中運作。1 一旦需要與 64bit 專用的 DLL、SDK、COM 元件整合，單一行程就無法完成任務。
  • 讀寫 Access .mdb / .accdb 的「Access Database Engine(ACE)」也受 32bit/64bit 的限制。一台機器只能安裝其中一種位元數，且必須與 Office 的位元數一致。2 自 Office 2019 / Microsoft 365 起，預設安裝已改為 64bit，因此依賴舊有 32bit 前提所建立的 Access 應用程式或 ActiveX 元件，換到新電腦的瞬間就可能無法運作。34
  • 在共用資料夾上讓多人同時開啟 .accdb 的運作方式，至今在現場仍相當普遍，但同時是造成損壞、效能下降的風險因素。官方已說明透過網路進行的寫入，一旦連線變得不穩定，就可能導致資料損壞。5 當台帳規模或同時使用人數增加，就是該考慮升級至 SQL Server 等方案的階段。
  • 判斷的軸心與 ActiveX / OCX 時相同，在於這項資產只是單純的畫面，還是承載業務邏輯與資料的邊界介面。穩定運作且範圍封閉就保留，只想局部現代化就包裝，UI 或執行基礎的限制正拖累事業腳步就取代，依此順序思考。

2. VB6 的現況 ── 執行環境仍存活，但開發已無後盾

首先要把前提說清楚。微軟已於 2008 年 4 月 8 日表明「Visual Basic 6.0 的 IDE(以及 Visual Studio 6.0 的 IDE)不再受支援」，明確表示已不再提供以正式手段建立、維護 VB6 應用程式的方式，並強烈建議改用現代技術。1

不過，同一份公告中也提到，VB6 執行環境只要搭載於仍在支援期內的 Windows 版本，就屬於運作對象。既有的 VB6 應用程式在對應的 Windows 上被預期能「原樣運作」，支援範圍僅限於嚴重的功能退化(regression)與重大安全問題的處理。1 換句話說，可以期待「裝在新版 Windows 上也不要壞掉」這種最低限度的保障，但不代表「遇到問題時會有人幫忙加新功能或個別調查」這種支援。

實務上另一個會產生影響的重點是，VB6 執行環境是 32bit 專用檔案，在 64bit OS 上只有在 WOW64 這個 32bit 模擬環境中才受支援。1 這意味著「VB6 應用程式今後也只能以 32bit 行程的形式存活」。當想使用 64bit 專用的量測儀器 SDK 或新的加密函式庫時，原則上無法直接載入 VB6 端的行程。要跨越這道牆，實質上只有「切出獨立行程來連接」這一條路，具體做法可以直接沿用「從 32bit 應用程式呼叫 64bit DLL 的 COM 橋接實例」中處理的內容。從 VB6 應用程式使用橋接時思路也一樣，把 64bit 功能封閉在跨行程 COM 伺服器或輔助 EXE 中，VB6 端只負責呼叫它。

多數 VB6 應用程式都把 ActiveX / OCX 控制項當作畫面元件內建其中。這些元件本身的保留・包裝・取代判斷，已在「現在該如何處理 ActiveX / OCX」中詳細討論，內嵌在 VB6 應用程式中的個別控制項判斷請參考該文。本文則把焦點放在如何處理整個 VB6 應用程式這個更高一層的判斷。

3. Access 的現況 ── 檔案格式・ACE 的位元數・共用資料夾的現實

3.1. .mdb / .accdb 與 ACE 的位元數

Access 的資料儲存在 .mdb(舊格式)或 .accdb(2007 以後)檔案中，負責讀寫的執行環境元件就是 Access Database Engine(ACE，Jet 的後繼者)。實務上頻繁發生的是位元數不一致的問題。傳統的 Jet OLE DB 提供者僅提供 32bit 版本，ACE 雖然同時提供 32bit / 64bit，但一台機器只能安裝其中一種，且必須與該機器 Office 的位元數一致，官方已如此說明。2 Visual Studio 方面也明確指出，Visual Studio 2022 以後已成為 64bit 行程，導致使用 32bit Access 提供者的資料工具無法連線的情況。6

更麻煩的是 Office 端預設值的變化。Office 2010～2016 預設安裝 32bit 版本，但自 Office 2019 及 Microsoft 365 起，預設安裝已改為 64bit 版本。3 加上 64bit 版 Office 行程無法載入 32bit 二進位檔，既有的 32bit ActiveX 控制項或 COM 增益集在 64bit Office 上無法直接運作。4 也就是說，「明明用了同一套 Access 應用程式好幾年，換了電腦卻突然無法運作」這類事故，多數原因是Office 位元數在預設值上發生了切換，而 ACE 或內嵌控制項的位元數沒能跟上。這類問題的排查步驟，已整理在「Office 2024/Microsoft 365 中 ActiveX 無法運作的原因與確認步驟」中。

3.2. 共用資料夾多人使用的風險

Access 應用程式另一個常見架構，是把 .accdb 放在共用資料夾上，讓多人同時開啟。規模小的話往往能長年順利運作，但這本質上是個危險的架構。官方已說明透過網路進行的寫入，一旦連線變得不穩定，就可能導致寫入失敗或檔案損壞，5 而檔案伺服器存取延遲或逾時時，Access 回報磁碟/網路錯誤的案例也早已為人所知。7 損壞的根源本身──對共用檔案的同時存取──與本部落格「檔案整合排他控制的基礎知識」中討論的競爭模式，結構相當類似。Access 內建了以鎖定檔(.laccdb)進行排他控制的機制，但透過 Wi-Fi 連線的筆電、VPN 遠端辦公、睡眠後重新連線這類「連線容易變得不穩定的路徑」越多，事故率就越高。

當同時使用人數增加，或處理變得沉重時，常見的解法是把 Access 的資料表遷移到 SQL Server 或 Azure SQL，Access 端改以連結資料表方式參照。使用 SQL Server Migration Assistant(SSMA)等工具遷移 Access 資料表後，把原本的 Access 資料表替換為指向遷移目標資料表的連結，就能讓畫面(表單、報表、查詢)維持原樣，只把資料移到更穩健的基礎上。8 不過連結資料表化也有遷移後特有的問題，例如彙總處理變慢(若依賴伺服器端無法執行的函式，Access 會把整張資料表先拉到本機再處理)、自動編號欄位的行為改變，有時需要改用直通查詢(pass-through query)或檢視表(view)來取代。8 此外，Access 應用程式一向建議分割成擁有資料表的「後端」資料庫，與擁有查詢、表單、報表、巨集的「前端」資料庫。9 這裡的重點是，光是分割並不夠。只把後端(資料表)放在共用資料夾，前端則複製並部署到每位使用者的電腦上，各自使用本機副本，才是正確的架構。若前端仍讓所有人共同開啟共用資料夾上的同一個檔案，即使已經分割，仍殘留著「對共用檔案中的畫面、查詢、巨集進行同時讀寫」的風險，會引發開啟等待時間變長、設計變更時衝突等問題。無論是維持共用資料夾運作延命，還是轉向 SQL Server，首先都要確認「後端共用」與「前端部署到各設備」這兩點是否都已完成，這是第一個檢查點。

4. 判斷表

把 VB6 應用程式與 Access 應用程式依使用狀況、風險因素整理，可以如下判斷：

對象 使用狀況・風險因素 建議
VB6 桌面應用程式 設備・Windows 版本固定，變更需求也小 保留
VB6 桌面應用程式 需要與 64bit 專用 DLL・SDK・COM 元件整合 包裝(64bit 輔助程式/COM 橋接)
VB6 桌面應用程式 開發者不在、原始碼散失，或改版需求頻繁 取代
VB6 應用程式內的 ActiveX/OCX 元件 僅為 UI 元件且有替代控制項 取代(以元件為單位)
VB6 應用程式內的 ActiveX/OCX 元件 承載裝置控制、報表等規格 包裝(先切出邊界)
Access 應用程式(個人使用・單一檔案) 單人使用，已有備份運作，無同時存取 保留
Access 應用程式(共用資料夾・少數人) 數人輪流使用，後端共用+前端已部署到各設備 保留(此架構下較容易延命)
Access 應用程式(共用資料夾・多人/持續同時存取) 同時使用者眾多，曾有損壞・延遲經驗 包裝(遷移至 SQL Server 連結資料表)
Access 應用程式(依賴 32bit ACE/ActiveX) Office 即將 64bit 化・設備即將更新 先驗證包裝/取代(第 3.1 節)
Access 的 VBA 邏輯 業務邏輯集中，且有與其他系統整合或網頁化需求 階段性取代(先 UI 後邏輯)

補充一點，這張表中的「包裝」多數情況下意味著先只讓資料或邊界現代化，畫面與操作感暫時維持不變。並非一次性重做全部，而是先處理風險較高的部分的一個暫時性落腳點。

判斷表的使用方式，是先鎖定「對象」這一行，再確認自己的狀況是否符合「使用狀況・風險因素」。同一個 VB6 應用程式中，某個畫面保留、某個功能包裝，依行、依功能分開判斷是很重要的。若把「因為是 VB6 應用程式就全部一視同仁」概括處理，反而會把原本可以保留的穩定部分也捲進來，使工時膨脹。

5. 依情境套用判斷的方式

把判斷表套用到實際諮詢案例，大致會收斂成以下 3 種模式。

情境 1：公司內部專用的庫存管理 VB6 應用程式，變更需求很小。 若目標設備固定在幾台，也不連上網路，判斷表會偏向「保留」。這裡的實務對應，就是踏實累積第 7 章的風險緩解措施(備份・文件化・鎖定執行環境)。除非有強烈動機遷移到 .NET，否則多數情況下成本效益並不合算。

情境 2：多部門共用的 Access 台帳，使用人數增加了。 幾年前只有 2～3 人使用的 Access 應用程式，因部門整合或業務擴大變成 10 人規模的同時存取，是常見的諮詢情境。此時判斷表偏向「包裝」。首先確認後端共用、前端已部署到各設備(第 3.2 節)，若尚未做到就先重新分割、部署。接著若已出現損壞或效能下降的徵兆(開啟等待時間變長、.laccdb 殘留導致鎖定無法解除等)，就把資料表遷移到 SQL Server，讓 Access 端改以連結資料表方式參照。8 畫面幾乎能原樣沿用，可在抑制使用者教育成本的同時只強化資料基礎。

情境 3：開發者已離職的 VB6 核心應用程式，出現網頁化需求。 原始碼還在，但沒人能碰，又出現想從公司外部使用的需求，此時判斷表偏向「取代」。不過越是核心系統，突然全面重寫的風險就越高。應依第 9 章的步驟，先從業務邏輯盤點與影響範圍小的功能切出開始，以階段性遷移推進較為現實。

6. 常見的反模式

在 VB6・Access 的延命・遷移案件中反覆出現的失敗模式，先在此分享。套用判斷表之前，請先確認是否已落入以下情況。

反模式 為什麼痛苦 優先的修正方式
因為「太舊了」就不篩選對象，直接決定全面重寫 規格挖掘與缺陷重現同時進行，工時無法預估 依判斷表逐行縮小對象，先從盤點開始
放任 32bit ACE / ActiveX 與 64bit Office 混用 每次設備更新都會發生「無法運作」的事故(第 3.1 節) 統一位元數，或切出邊界後包裝
讓共用資料夾上的 .accdb 無限制地增加使用人數 損壞・效能下降逐漸惡化(第 3.2 節) 後端共用+前端部署到各設備，或考慮升級至 SQL Server
VB6 的完整原始碼・依賴的 OCX 只存放在個人電腦上 離職・電腦故障會導致資產本身消失 集中到版本控制系統或共用儲存空間
「還能動就不動它」持續好幾年 沒有人能說明前提，保留的成本也看不清楚 將執行環境與依賴關係文件化(第 7 章)
只做了連結資料表化就滿足 依賴 Access 端函式的查詢無法在伺服器端執行，反而變慢 考慮改用直通查詢或檢視表8
未做業務邏輯盤點就直接重做 UI 隱藏的例外處理或計算邏輯遺漏，遷移後業務停擺 取代前先依 VBA・模組單位做盤點(第 9 章)

其中發生頻率特別高的，是位元數混用放任不管，以及共用資料夾多人化這兩項。兩者的共同點都不是「今天就會壞」，而是在設備更新或使用者增加這類遲早會到來的時機才顯現出來。

7. 選擇保留時的現實風險緩解對策

選擇保留在很多情況下是合理的判斷，這本身沒有錯。但「還能動就不動它」持續得越久，沒有人能說明前提的風險就累積得越多。至少應該處理以下事項：

  • 機械化執行備份世代管理。Access 的 .accdb 是單一檔案就能完結，光是每天做世代備份，就能吸收相當多的事故。VB6 應用程式則需要連同完整原始碼(.vbp, .frm, .bas, .cls)以及依賴的 OCX・DLL・登錄檔註冊資訊一起保存。
  • 作為後繼者不在的對策，將執行環境的前提文件化。至少要留下足以在「新電腦上無法運作時該確認什麼」層級的資訊，包括支援的 OS、Office 位元數、必要的執行環境・依賴 DLL・註冊步驟。
  • 刻意鎖定執行環境。由於 Windows 或 Office 的自動更新改變位元數或預設設定往往是事故的引信(第 3.1 節)，應對目標設備單獨分開更新政策，先驗證再展開更新後的版本。
  • 準備乾淨環境下的冒煙測試。在部署到新設備之前，先準備能在全新環境中確認安裝・註冊・啟動・主要操作都能通過的流程，可減少每次部署時卡在「應該能動卻不動」的時間。
  • 把呼叫點集中到一處。不要把 VB6 的 COM 呼叫或 Access 的連結資料表參照散布到整個應用程式，盡量把窗口收窄，未來要包裝或取代時，著手點會更明確。

VB6 特有的注意事項，還包括開發機本身的保存。IDE 的安裝媒體與授權、建置所需的外部控制項(OCX)開發者版本、建置步驟筆記，都是比執行環境更容易散失的資產。即使目前沒有改版計畫，只要把能重現建置的狀態保存為一套環境(例如虛擬機器快照)，未來真的需要小改版時，選項就會大幅增加。

若想在不破壞既有 Windows 軟體的前提下進行維護、改版，屬於既有 Windows 軟體的改版・維護的服務範圍。

8. 選擇包裝時的現實選項

「包裝」是把舊資產封閉在狹窄的邊界之內，對外則以新窗口的樣貌呈現的方法。VB6・Access 大致可歸納為以下 3 種模式。

(a) 從 .NET 透過 COM 互通呼叫 VB6 的 COM 元件。 若 VB6 寫成的類別模組以 ActiveX DLL(跨行程則為 EXE)公開，可以從 .NET 端透過 COM 互通呼叫。由於 VB6 端仍維持 32bit，從 64bit .NET 應用程式呼叫時，第 2 章提到的位元數之牆會以同樣的形式擋在前面。要把呼叫端統一為 32bit，還是封閉在跨行程 COM 伺服器成為 32bit 行程，這個選擇可以把「從 32bit 應用程式呼叫 64bit DLL 的 COM 橋接實例」的架構直接反過來套用。COM 本身的基礎知識請參考「COM / ActiveX / OCX 是什麼」。

(b) 把 Access 的 VBA 邏輯階段性移到 .NET / 網頁。 Access 應用程式中，有些在表單背後藏著濃密的業務邏輯，有些則僅止於單純的資料輸入・清單顯示，兩種情況混雜。實務上可行的做法，是先盤點 VBA 模組，把不依賴其他系統的純粹計算・驗證邏輯先切出為 .NET 類別庫，再讓 Access 端改為透過 COM 或中間的 Web API 呼叫。VBA 本身的限制，以及該保留到什麼程度在 VBA 內的判斷準則，已在「VBA 是什麼 - 限制、未來性與該取代的場景」中詳細整理。

(c) 先只取代 UI，資料與邏輯維持原狀。 若不滿主要集中在 Access 表單老舊、緩慢、無法在公司外使用，可以讓資料層(SQL Server 化的資料表)與邏輯維持原樣，只把 UI 換成網頁或桌面的新技術。結合第 3.2 節的連結資料表化，甚至可以做到「資料在 SQL Server，舊 UI(Access)與新 UI 看的是同一份資料」這種過渡性的雙軌運作。不過若 Access 端的 VBA 把 UI 與邏輯緊密耦合，這項分離工作本身必須先完成 (b) 的盤點才能成立。

整理這 3 個選項如下：

選項 適合場景 檢視重點
(a) 從 .NET 呼叫 VB6 COM 想沿用 VB6 端邏輯，只用 .NET 開發新畫面或周邊功能 位元數(統一為 32bit 或跨行程橋接)、註冊與部署
(b) 階段性移植 Access 的 VBA 邏輯 表單背後有濃密業務邏輯，且出現與其他系統整合的需求 分離純邏輯與 UI・DB 操作、設計呼叫路徑
(c) 先只取代 UI 主要不滿在於 UI 老舊・無法外部存取，資料與邏輯仍值得信任 資料層的分離程度、與舊 UI 並行的期間長短

若處於想先商討邊界劃分或遷移方針的階段，屬於既有資產活用・遷移支援；進入實作前的設計審查則屬於技術諮詢・設計審查的範圍。

9. 選擇取代時的推進方式

選擇取代，通常是因為 UI 或位元數的限制直接妨礙了事業發展速度，或開發者不在導致維護本身撐不下去。與其突然開始全面重寫，依以下順序推進可減少事故。

  1. 先做資料遷移驗證。 像 Access → SQL Server 這類資料遷移，會出現自動編號配發時機的差異、僅存在於 Access 端的函式依賴、唯一索引缺失等，只有遷移後才會顯現的差異。8 用正式資料的複本反覆測試遷移與業務情境，確認無誤後才進入正式切換。
  2. 盤點業務邏輯。 按功能單位梳理 VB6 的表單/模組，以及 Access 的 VBA/巨集/查詢內容，判斷是「單純的畫面」還是「承載規格的邊界介面」。這個判斷方式與 ActiveX / OCX 相同，但 VB6・Access 的情況下，多年運作累積的業務理解本身就是資產，因此挖掘起來較為費時，這是其特有的沉重之處。
  3. 以階段性遷移(strangler pattern)推進。 不是一次性取代所有功能，而是從風險低、獨立性高的功能先切出到新系統，讓舊應用程式與新應用程式並行運作一段時間。事先明確規定哪一方的資料為準，並訂定並行期間的結束條件，是讓這種做法不至於失敗的最低條件。
  4. 先完成 UI 元件或畫面結構的取代會比較輕鬆。 若 VB6 應用程式把 ActiveX / OCX 當作 UI 元件使用，先只把該元件換成現代化控制項，之後整體取代的估算會更容易。個別判斷請參考「現在該如何處理 ActiveX / OCX」。
  5. 準備並行期間的觀測手段。 舊應用程式與新應用程式並行運作期間，應準備能比較雙方處理結果的日誌或對照機制。若沒有觀測手段就推進切換，「切換到新系統後數字不對了」這種事故，可能要好幾個月後才會被察覺。

以老舊 Windows 應用程式的規格盤點到階段性取代為對象的服務，有Windows 應用程式重建。

10. 開始遷移時的檢查清單

在套用判斷表(第 4 章)之前，依以下順序先做盤點，可大幅縮短決定方針所需的時間。

  1. 列出對象。 把 VB6 的 .exe / .dll / .ocx、Access 的 .mdb / .accdb，依檔名・版本・存放位置整理成清單。
  2. 確認使用狀況。 確認使用者數量、是否有同時存取、是否為共用資料夾運作、使用頻率是每日還是每月。
  3. 確認執行環境的前提。 確認對應的 Windows 版本、Office 位元數、必要的執行環境・依賴 DLL・COM 註冊狀況(第 2～3 章)。
  4. 確認資料的所在與規模。 若是 Access，掌握檔案大小、資料表數量、記錄數與增加速度，作為判斷是否需要 SQL Server 化的依據。
  5. 估算業務邏輯的複雜度。 從 VBA 模組行數、巨集數量、表單數量，以及 VB6 端表單・類別模組的數量，估算盤點所需工時的大致範圍。
  6. 確認是否有備份與復原程序。 若尚未進行備份，或從未嘗試過復原，應在判斷之前先把這部分整頓好。
  7. 把以上結果套用到判斷表。 對象與使用狀況整理完畢後，依第 4 章的表格，依功能單位暫定應偏向保留・包裝・取代中的哪一種。

跳過這個步驟，往後就容易陷入無法說明「當初困難在哪裡」，卻工時不斷膨脹的局面。

11. 總結

決定 VB6・Access 該如何處理時，最先該看的不是「是否老舊」，而是以下 3 點：

  • 是否正確理解VB6 是失去 IDE 後盾的 32bit 專用執行環境這個前提(第 2 章)。
  • 是否已納入Access 的 ACE・ActiveX 受 Office 位元數束縛，共用資料夾運作在同時存取增加時損壞風險也會上升這個前提(第 3 章)。
  • 是否能判斷這項資產只是單純的畫面，還是承載業務邏輯與資料的邊界介面(第 4 章的判斷表)。

若能整理清楚這 3 點，就能自然地連結到後續行動：選擇「保留」就鎖定執行環境、不懈怠備份與文件化(第 7 章)；選擇「包裝」就用 32/64bit 橋接或階段性 .NET/網頁化守護資料與邏輯(第 8 章)；選擇「取代」就先做資料遷移驗證與業務邏輯盤點(第 9 章)。VB6・Access 並非因為老舊就該盲目丟棄的對象，而是承載著多年業務知識的實物。只是想繼續與這件實物打交道，鎖定執行環境・劃分邊界・遷移驗證這些課業，終究無法一直逃避下去。建議先依第 10 章的檢查清單著手盤點。

相關文章

相關諮詢領域

合同會社小村軟體提供包含 VB6・Access 的既有資產盤點與遷移方針整理、包含 32bit/64bit 橋接的延命設計，以及階段性重建的規劃與實作。

參考連結

  1. Microsoft, Visual Basic 6.0 Support Announcement. 說明 VB6 IDE / Visual Studio 6.0 IDE 於 2008 年 4 月 8 日起不再受支援，VB6 執行環境只要搭載於仍在支援期內的 Windows 版本即屬支援對象，以及執行環境為 32bit 專用，在 64bit OS 上僅在 WOW(WOW64) 環境下受支援。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Microsoft Learn, Microsoft OLE DB Provider for Jet and Jet ODBC driver are available in 32-bit versions only. 說明 Jet OLE DB 提供者/Jet ODBC 驅動程式僅提供 32bit 版本，ACE(Access Database Engine)雖有 32bit/64bit 兩種版本，但一台機器僅能安裝其中一種，且須與 Office 的位元數一致。 ↩ ↩2

  3. Microsoft Learn, 64-bit Visual Basic for Applications overview. 說明 Office 2010/2013/2016 預設安裝 32bit 版本，而自 Office 2019 及 Microsoft 365 起，預設安裝已改為 64bit 版本。 ↩ ↩2

  4. Microsoft Learn, Compatibility between the 32-bit and 64-bit versions of Office. 說明 64bit 版 Office 的原生行程無法載入包含 ActiveX 控制項的 32bit 二進位檔，既有 32bit ActiveX 控制項與 64bit Office 不相容。 ↩ ↩2

  5. Microsoft Learn, “Delayed Write Failed” error message states that your data has been lost. 說明對網路共用上的檔案進行寫入時，若因連線中斷等原因失敗，目標檔案可能損壞，且該處理責任在應用程式端。 ↩ ↩2

  6. Microsoft Learn, Connect to a database in Visual Studio. 說明 Visual Studio 2022 以後成為 64bit 行程，導致部分資料工具無法連接使用 32bit 版 OLEDB/ODBC 提供者(包括 32bit 版 Access OLEDB 提供者)的資料庫。 ↩

  7. Microsoft Learn, System stops responding, slow file server performance, or delays occur when you work with files that are located on a file server. 說明檔案伺服器存取延遲時，嘗試開啟 Access 的 .mdb 檔案可能發生「磁碟或網路錯誤」的案例。 ↩

  8. Microsoft Learn, Link Access applications to SQL Server and Azure SQL (AccessToSQL). 說明將 Access 的資料表遷移至 SQL Server / Azure SQL 後，把原本的資料表改為連結資料表參照的架構，以及遷移後可能出現的效能下降或自動編號欄位行為差異等問題。 ↩ ↩2 ↩3 ↩4 ↩5

  9. Microsoft Learn, Add and remove Access database files (AccessToSQL). 說明將 Access 資料庫分割為擁有資料表的後端資料庫，與擁有查詢・表單・報表・巨集・模組的前端資料庫的設計。 ↩

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

VB6 應用程式在現在的 Windows 上還能運作嗎？
VB6 的 IDE(開發環境)已在 2008 年 4 月正式終止支援，但 VB6 執行環境(msvbvm60.dll 等)只要搭載於仍在支援期內的 Windows，就屬於支援對象。也就是說，既有的 VB6 應用程式在對應的 Windows 上大致能持續運作。不過 VB6 僅支援 32bit，在 64bit OS 上是在 WOW64 相容環境中運作，一旦需要與 64bit 專用的 DLL、SDK、COM 元件整合，就必須切出獨立行程來連接。
更換 PC 之後 Access 應用程式突然無法運作，是什麼原因？
多數情況是 Office 位元數的變化所致。Office 2010～2016 預設安裝 32bit 版本，但從 Office 2019 及 Microsoft 365 起，預設安裝已改為 64bit 版本。負責讀寫 Access 資料的 ACE(Access Database Engine)在同一台電腦只能安裝 32bit 或 64bit 其中一種，且必須與 Office 的位元數一致。此外 64bit 版 Office 無法載入 32bit 的 ActiveX 控制項或 COM 增益集，因此依賴舊有 32bit 元件的部分，換到新電腦後便無法運作。
多人在共用資料夾中同時開啟 Access 檔案，這樣的做法有問題嗎？
這是造成損壞與效能下降的風險因素。透過網路進行的寫入，一旦連線變得不穩定，就可能導致資料損壞。透過 Wi-Fi 連線的筆電或 VPN 遠端辦公使用得越多，事故率就越高。至少應該只共用擁有資料表的後端，而擁有畫面與查詢的前端則複製到每位使用者的電腦上，採用這種分離架構。當同時使用人數增加時，就該考慮把資料表遷移到 SQL Server，讓 Access 端改以連結資料表的方式參照。
VB6/Access 應用程式該選擇保留、包裝，還是取代？
判斷的軸心在於，這項資產只是單純的畫面，還是承載業務邏輯與資料的邊界介面。若設備與 Windows 版本固定、變更需求也小，以備份、文件化、鎖定執行環境為前提保留下來，符合成本效益。若需要 64bit 整合或強化資料基礎，就用 COM 橋接或改為連結 SQL Server 資料表的方式只包裝一部分。若開發者已不在、維護已經撐不下去，或有網頁化需求，就該取代，但不是立刻全面重寫，而是先做資料遷移驗證與業務邏輯盤點的階段性遷移較為現實。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

聯絡我們
回到部落格一覽