我的任务是使用Access 97应用程序并将后端数据移动到SQL Server，同时将前端移动到Access 2003（使用Access Data Projects）。在此迁移过程中，后端数据结构将发生显着变化，以支持新功能。
如果我有我的愿望，我们就不会使用Access作为前端。我认为我们的应用程序可以通过WinForms，WPF或Web应用程序更好地服务。我们有足够的时间来正确规划业务逻辑层并实现一个出色的解决方案，但是我上面的权力希望继续使用Access，因为这是他们熟悉的。
我可以使用的帮助是继续沿着这条Access开发路径的利弊。使用Access 2003有什么合理的论据支持和反对？这是我到目前为止所提出的。
Pro Access：
反对访问
也许还有其他问题，我不知道赞成和反对Access的应用程序开发。我试图保持开放的心态，同时努力保持我的理智。
自从.NET发布以来，我一直在使用C＃，并且回到VBA六个月的想法让我头疼。特别是当我觉得如果允许用现代语言和工具开发的话我可以提供更多东西吗？
答案 0 :(得分：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 2010及其Access Services的新功能，这些功能允许您在Access中开发前端并在Web浏览器中运行它。这消除了对运行时的需求，这是一个很大的帮助。
但是现有的客户端Access应用程序没有轻松转换为Web Access应用程序。但是，有一个兼容性检查器可以告诉你哪些有效，哪些无效，所以这是一个选择，并非完全没有一些训练轮来帮助指导你进行转换。
考虑到应用程序及其生命周期的大局，以及Access和Sharepoint的未来，您可能会想出一套完全不同的答案。
另请注意，Access可能永远不会与VBA绑定。在A2010之后的接下来两个版本的Access之一中，我完全期待某种形式的.NET集成。另一方面，使用新的宏（现在具有错误处理和完整的分支结构），MS可能会从Access中删除任何特殊的脚本语言，并且只提供用于编程的大量增强的宏。
无法确定MS将在5到10年后使用Access的方向，但我们确实知道在最近两个版本中对Access进行了大量投资，而Access的未来现在与Sharepoint密切相关积分。知道这一点，你可能会对利弊的相对平衡得出不同的结论。
答案 1 :(得分：1)
当您尝试更改公司的开发工具时，请从公司的角度来看待它。也许有几位曾经在Access工作的经理人。在紧要关头，他们可以跳入并修复问题等。可维护性只对公司有意义，而不是对你个人而言。如果你写一个轰炸的网络应用程序，但公司中没有其他人有开发工具的经验，公司更糟糕的是不会更好，因为他们没有一个以上的开发人员可以跳入出错的地方，有人生病等等。
我同意HLGLM你应该升级到最新版本的Access而不是2003.由于运行时没有任何成本，最新的（2010）不会花费太多。
如果有多个开发人员，那么Access缺乏本机配置管理（版本控制）是对抗Access的强烈论据。
答案 2 :(得分：1)
仍支持ADP，但许多版本没有任何重大改进。因此，我建议将应用程序升级到Access 2003或更高版本，并使用运行时在客户端工作站上运行。请注意Access 2007运行时是免费的。
然后向后端向SQL Server保持Access数据库的MDB格式。创建删除Access中的瓶颈所需的视图和存储过程，并提高性能。无论你走向何方，你都会想要那些观点和存储过程。
<强>加 在升迁数据库时不要添加功能。首先让它顺利运行。
此时你和权力可以决定你想去的方向。
如果你要留在Access中，你可以一块一块地添加新功能。每周左右向用户提供这些更新。或者更常见的是我做的事情。
答案 3 :(得分：0)
就我而言，保持Access（以及更新版本）的唯一理由是，如果您不打算对前端功能进行任何更改，并且您的日程安排非常紧张。但是，如果您正在重构数据库并重做某些功能，那么继续使用Access是没有意义的。只是使后端SQL服务器也无法解决性能问题，您需要转换为使用存储过程而不是Access Jet引擎。
您是否可以将使用您熟悉的编程方法的想法作为项目副本中的成本节省来学习Access？也许如果你可以减少几个月的估计时间，那么就足以避免访问。
如果您遇到Access，至少让他们购买新的lisence并使用最新版本。 “升级”到过时的版本是愚蠢的。
报告看起来不错 - SQl Server有一个报告工具，也可以生成非常好的报告。在SSRS中编写一些报告并向他们展示他们有多好。在基于Web的应用程序中更改部署更容易 - 我很确定旧版本的Access很难部署（我在这里挖回我的内存）。如果我记得，你最终会陷入DDL地狱。足够的理由在那里避免它。使用基于Web的应用程序（他们确实有Intranet，不是吗？）部署非常简单，所有用户都可以立即部署，所有工作都可以完成而无需花费数天的时间来尝试让其他人使用其他人的版本。你也没有任何人使用过时版本的前端，这是另一个经典的Access问题。
向他们展示一个带有Access无法做到的仪表板的网络应用程序的时髦原型。如果他们放弃Access，就让他们想要获得的功能。
答案 4 :(得分：0)
我这很晚了，所以只是为了记录：ADP不允许你连接到多个服务器。这可能是一个停滞不前！