5

我的任务是使用 Access 97 应用程序并将后端数据移动到 SQL Server，同时将前端移动到 Access 2003（使用 Access Data Projects）。在此迁移过程中，后端数据结构将发生重大变化以支持新功能。

如果我有我的愿望，我们不会使用 Access 作为前端。我认为 WinForms、WPF 或 Web 应用程序会更好地为我们的应用程序提供服务。我们有时间正确规划业务逻辑层并实施出色的解决方案，但我之上的权力希望留在 Access 中，因为这是他们所熟悉的。

我可以使用的帮助是继续沿着 Access 开发这条道路前进的利弊。支持和反对使用 Access 2003 的正当理由是什么？到目前为止，这是我想出的。

专业访问：

  1. 已经拥有 Access 2003 许可证
  2. 简单的 GUI 开发
  3. 报告看起来不错

反对访问

  1. 必须使用 VBA（Visual Basic for Applications）
  2. ADO 与 DAO。Microsoft 没有将 Access 2002 更改为 Access 2003 吗？
  3. 不绑定到 Access 运行时
  4. 前端的选择（WPF、WinForms，甚至 ASP.NET）
  5. 可维护性
  6. 无法将逻辑与 UI 真正分离
  7. Microsoft 是否仍支持 Access ADP？

也许还有其他问题我不知道是否支持和反对应用程序开发的 Access。我试图保持开放的心态，同时努力保持理智。

自从 .NET 发布以来，我一直在使用 C#，而考虑回到 VBA 六个月的想法让我很头疼。尤其是当我觉得如果允许使用现代语言和工具进行开发，我可以提供更多？

4

5 回答 5

6

ADP 是围绕一个接口 ADO Classic（OLEDB 的包装器）构建的，它是孤立的，不会进一步发展。在 A2007 和 A2010 中，ADP 保持不变，这表明 MS 可能正在评估是否对它们执行对数据访问页 (DAP) 所做的处理，即在两个版本没有更改 (A2002/A2003) 之后，删除他们完全（A2007）。

但是，MS 也有可能对 ADP 做一些事情，因为 Access 团队最近在其博客上询问 SQL Server 用户关于可以在 Access 中进行哪些更改以使其更易于与 SQL Server 一起使用的反馈。该反馈将进入下一版本的 Access 之一（A2010 之后的版本或下一个版本）。这可能采取 ADP 恢复发展的形式，也可能采取完全不同的形式。我希望是后者，因为 Access 团队非常坚定地致力于将 Access 与 Sharepoint 集成（效果很好，我可能会补充），并且鉴于 Sharepoint 构建在 SQL Server 之上，我希望以 Sharepoint 为中心SQL Server“问题”的解决方案。

但我这里根本没有任何内幕消息。

在您目前的情况下，您已经开发了一个现有的 MDB。将现有的 MDB 移植到 ADP 确实不是一个简单的过程——您不能只执行 SAVE AS，也没有转换例程。这是因为 ADP 和 MDB 是完全不同的动物。MDB 是 Jet 数据库，而 ADP 是不使用 Jet 的容器文件。例如，ADP 中的对象不一定具有与 MDB 中相同的属性和行为，因此您不能只导入它们。

因此，“转换”为 ADP 需要几乎完全重写，在我看来，难度级别与移植到 WinForms 或其他完全不同的平台（尽管我从未使用过 ADP 或WinForms，所以我可能会误判）。我所知道的是，ADP 和 MDB 完全不同，以至于它们都是 Access 的事实错误地表明它们在某种程度上彼此兼容或可转换——它们不是！

鉴于 Access ADP 的未来不确定，我不建议以这种格式开始新的开发，更不用说将现有的 MDB 应用程序转换为 ADP。

对我来说，这很容易——转换为 A2003 并在很少或根本没有时间投入到该过程中的情况下完成它。

如果回报很大，我只会考虑移植，但您没有列出 Access 应用程序本身的任何缺陷——您所概述的只是您不喜欢 Access 开发模型。您可以将时间线延长一点，并考虑此应用程序的生命周期。您还应该熟悉与 Sharepoint 2010 及其 Access Services 集成的 Access 2010 的新功能，这些功能允许您在 Access 中开发前端并在 Web 浏览器中运行它。这消除了对运行时的需求，这是一个很大的帮助。

但是，将现有客户端 Access 应用程序转换为 Web Access 应用程序并不容易。但是，有一个兼容性检查器可以告诉您哪些有效，哪些无效，因此它不是完全没有一些辅助轮来帮助指导您进行转换的选择。

考虑到应用程序的大局及其生命周期，以及 Access 和 Sharepoint 的未来，您可能会想出一套完全不同的答案。

另请记住，Access 可能不会永远与 VBA 绑定。我完全期望在 A2010 之后的下两个 Access 版本之一中的某个时间，某种形式的 .NET 集成。另一方面，使用新的宏（现在具有错误处理和完整的分支结构），MS 可能会从 Access 中删除任何临时脚本语言，并仅提供大大增强的宏进行编程。

无法确定 MS 将在 5 到 10 年后与 Access 往哪个方向发展，但我们确实知道在过去两个版本中对 Access 进行了巨额投资，而 Access 的未来现在与 Sharepoint 集成密切相关。知道了这一点，您可能会对利弊的相对平衡得出不同的结论。

于 2010-05-03T22:16:38.613 回答
1

当您尝试更改公司的开发工具时，请从公司的角度来看待它。也许有几个经理曾经在 Access 中工作。在紧要关头，他们可以介入并解决问题等。可维护性只对公司有意义，而不是对您个人。如果您编写了一个出色的网络应用程序，但公司中没有其他人有开发工具方面的经验，那么公司的情况会更糟，而不是更好，因为他们没有超过一个开发人员可以跳出问题，有人生病等

我同意 HLGLM 的观点，即您应该升级到最新版本的 Access 而不是 2003。由于运行时不需要任何费用，因此最新版本（2010）不会花费太多。

如果开发人员不止一个，那么 Access 缺乏本机配置管理（版本控制）是反对 Access 的一个强有力的论据。

于 2010-05-03T22:35:15.710 回答
1

ADP 仍受支持，但许多版本没有任何显着增强。因此，我建议将应用程序升级到 Access 2003 或更新版本，并使用运行时在客户端工作站上运行。请注意，Access 2007 运行时是免费的。

然后将后端向上传输到 SQL Server，将 Access 数据库保持为 MDB 格式。创建必要的视图和存储过程，以消除 Access 中的瓶颈并提高性能。无论您朝哪个方向发展，您都将需要这些视图和存储过程。

已添加 在升级数据库时不要添加功能。先让它平稳运行。

在这一点上，你和当权者可以决定你想走的方向。

如果您要留在 Access 中，您将逐个添加新功能。每周左右向用户提供这些更新。或者更多时候，这就是我所做的。

于 2010-05-04T20:39:28.300 回答
0

就我而言，继续使用 Access（以及更新版本）的唯一原因是，如果您不打算对前端功能进行任何更改，并且您的日程安排非常紧张。但是，如果您正在重组数据库并重做一些功能，那么我继续使用 Access 是没有意义的。只是做后端 SQL 服务器也不能解决性能问题，您需要转换为使用存储过程而不是 Access Jet 引擎。

你能推销使用你熟悉的编程知识来节省项目成本的想法吗？也许如果您可以将估计的时间缩短几个月，那么就有足够的理由避免使用 Access。

如果您坚持使用 Access，至少让他们购买新的许可证并使用最新版本。“升级”到过时的版本是愚蠢的。

至于报告看起来不错 - SQl Server 有一个报告工具，它也可以制作非常漂亮的报告。在 SSRS 中生成一些报告，并向他们展示它们有多好。在基于 Web 的应用程序中部署更改更容易 - 我很确定旧版本的 Access 部署起来很糟糕（我在这里挖掘我的记忆）。如果我记得的话，你最终会进入 DDL 地狱。有足够的理由来避免它。使用基于 Web 的应用程序（他们确实有 Intranet，不是吗？）部署非常简单，所有用户都可以立即部署，一切正常，无需花费数天时间试图让一台流氓机器工作，而其他人的版本都可以。也没有人使用过时的前端版本，这是另一个经典的 Access 问题。

向他们展示一个漂亮的 Web 应用原型，其中包含 Access 无法做到的仪表板。让他们想要放弃 Access 后可以获得的功能。

于 2010-05-03T19:55:35.590 回答
0

我对此很晚，所以只是为了记录：ADP 不允许您连接到超过 1 个服务器。那可以是一个炫耀！

于 2011-05-02T13:45:11.887 回答