1

最近有人要求我更新旧的 Access Forms 应用程序。来自 .NET 背景，我发现这种变化令人恐惧，并且有点不舒服。我原以为这些是遗留技术，很快就变成了不合时宜的东西……

我错了吗？如果是这样，继续使用这项技术的原因是什么（除了避免将旧应用程序移植到 .NET 的成本）？

4

4 回答 4

28

与其回答问题的潜台词（即 Access 应用程序无论如何都很糟糕），我将提供一些有关 Access 未来的信息：

  1. Access 是 Microsoft 的旗舰产品。它在微软的产品线中无可替代，因此在可预见的未来，微软将继续以某种形式推广和开发它（只要有微软的Office套件，就会有Access）。

  2. Access 提供的功能在 MS 之外几乎没有竞争。唯一可比的产品是 FileMaker Pro。有人可能会说 OpenOffice 套件中的 Base 组件是竞争对手，但它仅涵盖 FM 和 Access 提供的功能的子集（这并不是说它可能不足以满足任何数量的场景）。

  3. Access（以及整个 Office 套件）仍在使用 VBA 作为其编程语言，而 Microsoft 的其余部分已从 VB 转向基于 .NET 的语言。其他 Office 产品现在可以使用 .NET 组件（尽管与使用 VBA 的方式不同），但 Access 并非如此。我希望在接下来的几个 Access 版本（不在A2010 中）的某个时候，将以某种方式引入 .NET 支持。但是了解 MS 的历史，VBA 将继续支持多个版本。

  4. Access 应用程序在 Web 部署方面一直存在巨大的弱点，FileMaker 几年前就提供了这种弱点。A2010 通过 Sharepoint 集成纠正了这一重大问题，允许使用新的 Web 对象创建 Access 应用程序，这些对象可以在 Access 客户端和 Web 浏览器（任何符合标准的 Web 浏览器 - 不再有 Web 组件和限制IE）。

  5. Jet 数据库引擎基本上在 Jet 4 发布时（1999 年发布）被 MS 宣布死亡，尽管 MS 将 Jet 4 变成了 Windows 操作系统的一个组件（现在仍然如此）。随着 Access 2007 的发布，Jet 获得了新的生命，包括一个名为 ACE 的新版本的 Jet 数据库引擎，由 Access 开发团队所有（Jet 4 继续由 Windows 开发团队所有，并按原样冻结，没有额外的发展）。ACE 中引入的许多新功能都是由 Microsoft 将 Access 与 Sharepoint 集成的目标驱动的，但在 A2010 中，一些新功能（如表级数据宏，它启用了触发器的等效功能）即使没有使用 Sharepoint（其他，如多值字段，则不是）。使用 64 位版本的 Office，有

现在，最后一个问题：

@ChrisDiRulli 问：

有什么理由继续使用这项技术（除了避免转移它的成本）？

当然，继续使用 Access 有很好的理由：

  1. 该应用程序已经开发。

  2. 该应用程序运行良好，或运行良好以完成工作。

  3. 该应用程序只需要一些新功能，而不是完全重写。

  4. 该应用程序由一组没有部署问题的用户使用（他们都具有完全访问权限或正在使用运行时）。

在我看来，Access 有着美好的未来。自从 Office 95/97 发布以来，我就没有对 Access 如此热衷，它将 VBA 引入到 Office 套件中，并允许在 Office 套件之上创建“元应用程序”。

现在，在任何特定情况下，对于旧版 Access 应用程序，问题可能是没有人知道如何修复现有应用程序，或者现有应用程序是意大利面条代码和宏的一团糟（如果它使用宏会更糟，因为它是几乎不可能说出它们是如何相互关联的），或者架构不好，或者，或者，或者....

如果问题是没有人有能力（或兴趣）来拯救应用程序，您应该考虑聘请一位经验丰富的 Access 开发人员。找到这些人并不是那么简单，但那里有很多人。您可以通过他们在 Access Usenet 组中的公开帖子甚至在 SO 上的一些帖子来判断谁是胜任者。

如果您不想这样做，您可能会花费更多的钱，要么四处寻找如何修复 Access 应用程序，要么发现在 Access 之外复制相同的功能是多么昂贵。在后一种情况下，许多组织选择将应用程序替换为仅提供一小部分相同功能的应用程序。这是一种疏远最终用户的好方法，并促使他们朝着取消预订的方向发展，并且将来不再向 IT 寻求帮助，因此这可能不是一个好主意。

但首先要做的是：

失去对 Access 的敌意。这是不合理的，99.99% 的可能性是完全基于无知。

于 2010-02-12T18:23:24.463 回答
9

仍然有大量的软件是用 COBOL 编写的，而且比 Access 还要古老得多。

在某些领域，Access 应用程序可能就足够了，而且是最便宜的选择。如果它完成了工作（你的工作部分是让你的雇主知道它是否真的完成了工作）并且如果这是他们想要的，那就去做吧。

如果您认为 .NET 项目会更好或 Access 将达不到要求的充分理由，请公开讨论它们并尝试做出符合削减支票的人的最佳利益的决定。

于 2010-02-12T17:21:46.663 回答
4

我们保留它，因为它有效。当企业的需求增长如此之快以至于 Access 应用程序无法再完成工作时（这对企业来说是一件非常好的事情，或者是您的 Access 开发人员可能缺乏这方面知识的不幸迹象。），您构建的东西可以或雇用可以的人。

您对所有开发人员都经历的感到沮丧。我从来没有开始思考，“ &^% &，我必须构建一个新的应用程序！我什么时候才能回到那个 3 年前的 .NET 代码并修复它......” 重构有它的位置.

现在，我希望在 Access 中看到许多 .NET 功能，并期待 2010 版本。

于 2010-02-12T18:28:03.703 回答
3

为正确的工作使用正确的工具。许多 IT 人员因为不得不维护一些刚刚退出 excel 的人制作的糟糕的数据库而被推迟访问。然而，访问有很多事情要做。例如，我有一个项目即将推出，需要在短时间内快速推广到大约 10 个用户。对于这项工作，我将 SQL 服务器和 Visual Studio 的副本留在架子上并使用访问权限。如果访问适合这项工作，那么为什么要在 .net 中重写它，以便它可以在 .net 中。对我来说，使用的编程工具是达到目的的手段而不是功能

于 2010-02-12T22:32:23.270 回答