在我看来，就像 MS-ACCESS 问题具有吸引更广泛 * 人群的标签几乎总是如此，回答的人在这里错过了关键问题，我将其解读为：
是否有任何工具可以成功地将 Access 应用程序转换为任何其他平台？
答案是
绝对不会
原因很简单，同一家族中使用类似模型的 UI 对象（例如 VB6）的工具缺少 Access 默认提供的很多东西（如何将 Access 连续子窗体转换为 VB6 而不是失去功能？）。其他平台甚至不共享与 VB6 和 Access 相同的核心模型，因此需要清除更多障碍。
引用的 MySQL 文章非常有趣，但它确实混淆了不称职的应用程序所带来的问题与所使用的开发工具所带来的问题。糟糕的数据架构不是 Access 所固有的——它是 [大多数] 新手数据库用户所固有的。但文章似乎将此问题归咎于 Access。
并且完全忽略了修复架构、将其升级到 MySQL 并将前端保留在 Access 中的可能性，这是迄今为止解决问题的最简单方法。
这正是我对那些没有获得 Access 的人的期望——他们甚至不认为 Access 作为安全、大容量服务器数据库引擎的前端可以成为解决问题的最佳解决方案。
那篇文章甚至没有真正考虑转换 Access 应用程序，这是有充分理由的。我见过的所有声称可以转换 Access 应用程序（到任何平台）的工具，要么只转换数据（在这种情况下，它们根本不转换应用程序——白痴！），要么盲目地转换前端结构，在 Access 应用程序和目标应用程序中的 UI 对象之间具有 1:1 的对应关系。
这不起作用。
Access 的应用程序设计是特定于自身的，其他平台不支持相同的一组功能。因此，必须将 Access 功能转换为转换后的应用程序中原始功能的有效替代品。在我看来，这不是可以以自动化方式完成的事情。
其次，当考虑将 Access 应用程序转换为在 Web 浏览器中进行部署时，整个应用程序模型是不同的，即从有状态到无状态，因此这不仅仅是一些不受支持的 Access 功能的问题，而是UI 对象如何与数据交互的完全不同的基本模型。也许一个 100% 未绑定的 Access 应用程序可以相对容易地转换为基于浏览器的实现，但是有多少呢？这将意味着一个不使用任何子表单的 Access 应用程序（因为它们不能被解除绑定），以及一个仅使用来自丰富事件模型的少数事件的应用程序（其中大部分仅适用于绑定的表单/控件）。简而言之，一个 100% 未绑定的 Access 应用程序将与整个 Access 开发范式作斗争。任何认为他们想在 Access 中构建未绑定应用程序的人真的不应该首先使用 Access，因为 Access 的全部意义在于绑定的表单/控件！如果您消除了这一点，您就失去了 Access 相对于其他开发平台的大部分 RAD 优势，并且几乎没有获得任何回报（除了巨大的代码复杂性）。
要在 Web 浏览器中构建应用程序以完成与 Access 应用程序相同的任务，需要从头开始重新设计应用程序 UI 和工作流。因为成功的 Access 应用程序模型与成功的 Web 应用程序模型是对立的，所以没有任何转换或翻译会起作用。
当然，所有这些都随着 Access 2010 和带有 Access Services 的 Sharepoint Server 2010 而改变。在这种情况下，您可以在 Access 中构建您的应用程序（使用 Web 对象）并部署在 Sharepoint 上，以便用户在浏览器中运行它。结果在功能上 100% 等效（视觉效果为 90%），并且可以在所有浏览器上运行（此处没有 IE 特定的依赖项）。
因此，从今年 6 月开始，将 Access 应用程序转换为在浏览器中部署的最便宜的方法很可能是升级到 A2010，将设计转换为使用所有 Web 对象，然后使用 Sharepoint 进行部署。这不是一个简单的项目，因为 Access Web 对象与客户端对象相比具有有限的一组功能（例如，没有 VBA，因此您必须学习新的宏，它们比旧的更强大和安全，因此，对于那些熟悉 Access 的旧版宏的人来说，这并不是什么可怕的困难），但与在 Web 上进行全面重新设计相比，它的工作量可能要少得多。
另一件事是它不需要对最终用户进行任何重新培训（只要 Web 对象版本与原始客户端版本相同），因为它在 Access 客户端中与在 Web 中相同浏览器。
所以，简而言之，我会说转换是一种幻想，而且几乎总是不值得付出努力。事实上，我同意所引用的观点（即使我对该来源的其他 cmets 有很多问题）。但我也警告说，转换的愿望经常被误导，并且错过了不需要从上到下批量更换 Access 应用程序的更便宜、更简单和更好的解决方案。对 Jet/ACE 作为数据存储的不满常常使人们误以为他们也必须更换 Access 应用程序。确实，许多用户开发的 Access 应用程序都充满了可怕的、无法维护的妥协，并且与口香糖和钢丝绳结合在一起。但是，一个设计糟糕的 Access 应用程序可以与后端的数据架构的扩容和修改一起改进——它不必被丢弃。
这并不意味着它很容易 -- 通常情况下并非如此。正如我一直告诉客户的那样，建造新房子通常比改造旧房子更容易。但是我们改造老房子的原因之一是因为它们具有我们不想失去的不可替代的特征。通常情况下，Access 应用程序隐含地包含许多业务规则和工作流建模，这些不应在新应用程序中丢失（旧的 Netscape 难题，步伐 Joel Spolsky）。对于试图移植到不同平台的外部开发人员来说，这些事情可能并不明显，但对于最终用户来说，如果应用程序产生的结果与旧应用程序相比相差一分钱，他们会不高兴（并且可能应该是，因为这可能意味着应用程序的其他方面也没有产生可靠的结果）。
无论如何，我已经讨论了太久了，但我的观点是，除了最琐碎的应用程序（或旨在转换的应用程序，例如 100% 未绑定的 Access 应用程序），转换永远不会起作用。我完全赞成修改而不是替换。
但是，当然，这就是我谋生的方式，即修复 Access 应用程序。