小村软件有限公司
日本語 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 操作系统上，是在 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 操作系统上只有在 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)或视图来替代。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 逻辑 业务逻辑集中，且有与其他系统对接或 Web 化需求 分阶段替换(先 UI 后逻辑)

补充一点，这张表里的“封装”多数情况下意味着先只让数据或边界现代化，界面与操作体验暂时保持不变。不是一次性把全部推倒重做，而是先处理风险较高的部分的一个临时落脚点。

判断表的用法，是先锁定“对象”这一行，再确认自己的情况是否符合“使用状况・风险因素”。同一个 VB6 应用里，某个界面保留、某个功能封装，按行、按功能分开判断这一点很重要。如果因为“是 VB6 应用就全部一视同仁”而笼统处理，反而会把本来可以保留的稳定部分也牵连进来，导致工作量膨胀。

5. 按场景套用判断的方式

把判断表套到实际咨询案例中，大致会收敛成以下 3 种模式。

场景 1：公司内部专用的库存管理 VB6 应用，变更需求很小。 如果目标设备固定在几台，也不联网，判断表会偏向“保留”。这里的实务应对，就是踏实地积累第 7 章的风险缓解措施(备份・文档化・固定运行环境)。除非有强烈动机迁移到 .NET，否则多数情况下成本效益都算不过来。

场景 2：多部门共用的 Access 台账，使用人数增多了。 几年前只有 2～3 人使用的 Access 应用，因部门整合或业务扩张变成 10 人规模的并发访问，是常见的咨询场景。这时判断表偏向“封装”。首先确认后端共享、前端已部署到各设备(第 3.2 节)，如果还没做到就先重新拆分、部署。接着如果已经出现损坏或性能下降的迹象(打开等待时间变长、.laccdb 残留导致锁定解不开等)，就把数据表迁移到 SQL Server，让 Access 端改为以链接表方式引用。8 界面几乎能原样沿用，可以在压低用户培训成本的同时，只把数据基础打牢。

场景 3：开发者已离职的 VB6 核心系统，出现 Web 化需求。 源码还在，但没人能改动，又冒出了想从公司外部访问的需求，这种情况下判断表偏向“替换”。不过越是核心系统，突然全面重写的风险就越高。应该按第 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・注册表登记信息一起保存。
  • 作为后继者缺位的对策，把运行环境的前提文档化。至少要留下能达到“新电脑上跑不起来时该检查什么”这个粒度的信息，包括支持的操作系统、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 / Web。 Access 应用中，有些在表单背后藏着浓密的业务逻辑，有些则仅止于单纯的数据录入・列表显示，两种情况混在一起。实务中可行的做法，是先盘点 VBA 模块，把不依赖其他系统的纯计算・校验逻辑先拆出为 .NET 类库，再让 Access 一侧改为通过 COM 或中间的 Web API 调用。VBA 本身的局限性，以及应该在 VBA 里保留到什么程度的判断依据，已经在「VBA 是什么 - 局限性、未来走向与该替换的场景」中详细整理过。

(c) 先只替换 UI，数据与逻辑维持原样。 如果不满主要集中在 Access 表单老旧、慢、没法在公司外面用，可以让数据层(SQL Server 化后的表)与逻辑保持原样，只把 UI 换成 Web 或桌面端的新技术。结合第 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/Web 化来守护数据与逻辑(第 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 操作系统上仅在 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 操作系统上是在 WOW64 兼容环境中运行，一旦需要与 64bit 专用的 DLL、SDK、COM 组件对接，就必须拆分出独立进程来连接。
换了台电脑之后 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 表的方式只封装一部分。如果开发者已经离职、维护已经跟不上，或有 Web 化需求，就该替换，但不是立刻全面重写，而是先做数据迁移验证与业务逻辑盘点的分阶段迁移更现实。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。

联系我们
返回博客列表