访问ADP - 对/对？

Question

我一直负责采用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（视觉基本的应用程序）
2. ADO vs DAO。微软没有将Access 2002中的东西改变为Access 2003？
3. 不依赖于前端要接入运行
4. 选择（WPF，WinForms的，甚至是ASP.NET）
5. 可维护性
6. 从UI不可能
7. 微软是否仍然支持Access ADP逻辑的真正分离？

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

自从.NET发布以来，我一直在使用C＃，想到回到VBA六个月会让我头疼。特别是当我觉得如果允许用现代语言和工具进行开发，我可以提供更多的东西？

Answer 1

ADP是围绕着一个界面ADO Classic（一个围绕OLEDB的包装）构建的，它是孤立的，不会看到进一步的发展。在A2007和A2010中，ADP保持不变，这表明MS很可能会评估是否对他们做了什么（使用数据访问页面（DAP）），即在两个版本没有更改（A2002/A2003）之后，删除他们完全（A2007）。

但是，MS也可能会对ADP做些事情，因为Access团队最近在其博客上询问了一些问题，要求SQL Server用户提供有关Access中可以更改哪些内容的反馈，以便更容易地使用SQL服务器。该反馈将进入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浏览器中运行它。这消除了运行时的需要，这是一个很大的帮助。

但有没有简单的转换现有的客户端访问应用程序的Web访问应用程序。然而，有一个兼容性检查器可以告诉你什么有效，什么不可以，所以这是一个不完全没有一些训练轮帮助指导你转换的选择。

考虑到应用程序和其寿命的大画面，以及访问和Sharepoint的未来，你可能会拿出一套完全不同的答案。

也请记住，这很可能是访问不会永远依赖于VBA。在A2010之后的下一个Access版本中，我完全期待某种形式的.NET集成。另一方面，使用新的宏（现在有错误处理和完整的分支结构），MS可能会从Access中删除任何特定的脚本语言，并且只提供用于编程的大量增强的宏。

我们无法确定MS将在访问5 - 10年后走向哪个方向，但我们确实知道在最后两个版本中存在对Access的巨大投资，而且Access的未来与现在密切相关Sharepoint集成。知道这一点，你可能就利弊的相对平衡得出不同的结论。

Answer 2

就我而言，保持Access（以及更新版本）的唯一理由是如果您不打算对前端功能进行任何更改并且时间紧迫。但是，如果您正在重构数据库并重做某些功能，那么使用Access就没有意义了。只是制作后端SQL服务器也不能解决性能问题，您需要转换为使用存储的procs而不是Access Jet引擎。

您是否可以出售使用您熟悉编程的概念作为项目负责人回溯学习Access的成本节约？也许如果你可以削减几个月的时间估计，这将是足够的理由，以避免访问。

如果你坚持使用Access，至少让他们购买新的lisence并使用最新版本。将“升级”为过时的版本很愚蠢。

只要报告看起来不错 - SQl Server有一个报告工具，报告也非常好。在SSRS中创建一些报告并向他们展示他们的成绩。在基于Web的应用程序中部署更改更容易 - 我敢肯定，早期版本的Access很难部署（我在这里挖掘我的记忆）。如果我记得，你最终会死在DDL里。有足够的理由来避免它。使用基于Web的应用程序（他们确实拥有内联网不是吗？）部署非常简单，所有用户都可以立即部署，而且一切都可以正常工作，而无需花费数天的时间试图在其他人的版本上运行一台恶意机器。您也没有任何人使用过时的前端版本，这是另一个经典的Access问题。

向他们展示一个带有Access之类的仪表板的Web应用程序的时髦原型。让他们想要他们可以得到的功能，如果他们沟通Access。

Answer 3

当您尝试更改公司的开发工具时，从公司的角度来看它。也许有几个经理曾经在Access工作过。在一个捏，他们可以跳进来解决问题等。可维护性只对公司有意义，而不是对你个人。如果你写了一个爆炸性的web应用程序，但公司里没有其他人拥有开发工具的经验，那么这家公司的情况就不会好些了，因为他们没有多个开发人员可以跳出一些错误，有人生病等

我HLGLM，你应该升级到访问，而不是2003年的最新版本，同意由于运行时没有任何费用，最新（2010年）将花不了多少钱。

如果有曾经将是一个以上的开发，然后访问缺乏本地配置管理（版本控制）是针对访问一个有力的论据。

Answer 4

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

然后upwise后端到SQL Server保持在MDB格式的Access数据库。创建必要的视图和存储过程，以删除Access中的瓶颈并提高性能。不管你走的是什么方向，你都会想要这些视图和存储过程。

已添加 在升迁数据库时不要添加功能。先让它顺利运行。

此时你和那些能决定你想要去的方向的力量。

如果您要留在Access中，您可以逐个添加新功能。每周为用户提供这些更新。或者更常见的是我所做的。

Answer 5

我对这个很晚了，所以它只是备案：ADP不允许您连接到超过1台服务器。这可能是一个炫耀者！