移植MS Access应用程序

Question

有朋友要求我帮助他评估将基于MS访问和VBA的桌面应用程序移植到基于Web的应用程序的引用数量。该应用程序似乎有相对大量的业务逻辑编码到VBA中。

我的问题非常具体 - 是否有任何好的工具或资源可以帮助移植访问，而不是完全重写？

用于网络应用程序的最终技术无关紧要，但理想情况下应尽可能为主流。

Answer 1

您可以探索Sharepoint提供的各种可能性。它可以帮助您在线访问数据，但这项工作的效果还取决于Access应用程序中使用了多少VBA代码。

有一些工具可以假装他们可以将MS Access转换为PHP / ASP网站，例如DB Forms，但我没有尝试过，他们通常只转换应用程序的可见部分，而不是查询和VBA。
它们可以帮助你开始。

随机想法

VBA往往是最大的问题。 转移到ASP.Net需要时间，因此您面临着困难的选择：

1. 将所有代码传输到ASP.NET以使其正常工作
2. 重新考虑结构并从头开始进行适当的ASP.Net实施。

我更喜欢第一个：尽可能快地尝试快速获得结果 使用SSMA将数据移动到SQL Server（除非您希望将Access保留为后端） 使表单看起来与现有应用程序相同（或者至少具有相同的功能），将VBA移植到VB.Net（或C＃，如果您愿意的话）通过表单，逐个模块和测试它们的工作形式你去吧。

在这个阶段不要试图重构或改进事物，重点是在新的“系统”上“敲打”旧代码并使其像过去那样吠叫，而不是更好，不会更糟。

只有这样，您才能开始使用新工具进行重构和改进。

我说这一切都假设旧应用程序没有什么特别的错误，只需将其移植到网上消费。

如果旧的应用程序存在缺陷并且没有履行其职责，那么应该更多地强调重新思考应该翻译哪些部分以及应该重新编写哪些部分。

无论如何，您需要制定详细的行动计划并审查当前的代码和功能，并尝试尽可能限制您对新系统第一版的期望：避免让每个人输入他们的意愿或你的项目将变得非常困难。

专注于达到满足用户需求的特定功能所需的最低要求，然后以此为基础。

Answer 2

对于某些基本内容可能有一些工具，比如升级到不同的数据库，或者可能是表单的外观和文本框，但转换听起来像很多VBA代码的东西，不太确定。

这是一个内部网/本地网络类型的网络应用程序还是你把它放在互联网上？安全性将成为此应用与您的Access应用之间的主要区别。

确保他们了解Access / VBA，以便您可以维护Access应用程序生命周期中的业务逻辑。

说服您的朋友停止/放慢Access应用程序上的任何开发，以防止公司瞄准移动目标。这可能不太现实，但确实需要考虑。

Answer 3

是否有理由在Windows终端服务器上托管应用程序是不够的？这意味着对应用程序零更改，无需重新编程成本，也没有丢失关键业务逻辑的危险。如果您使用Citrix扩展，您可以在Web浏览器中运行它（虽然我猜这只适用于IE - 我从未使用它们）。但是RDP客户端有适用于Mac和Linux以及Windows的版本，所以只要他们为他们的操作系统安装RDP客户端，你基本上可以支持任何人。

是的，它在客户端更多安装，但它在开发上更便宜，更容易，并且避免了丢失编码到Access应用程序中的重要事物的问题。

当然，在WTS / Citrix上支持大量用户群可能会变得昂贵，如果Access应用程序需要重新设计，无论如何，它可以改变平衡。但这是你应该考虑的事情。事实上，真的 很容易设置WTS，并为它配置服务器基本上是增加RAM和互联网带宽的问题（虽然RDP真的很有用）。

许多人在尝试在WTS上运行Access应用程序时犯了一个关键错误：

您必须拆分数据库（前面有表格/报告/等，后端只有数据表），每个用户必须拥有自己的前端副本（存储在WTS上的用户配置文件中，或者存储在用户配置文件中） WTS服务器数据分区上的文件夹，具有分配给授权使用该应用程序的用户组的相应权限。 Tony Toews's front-end updater在此上下文中非常有用，并且明确设计为在终端服务器环境中工作。