我的任务是获取Access 97应用程序并将后端数据移动到SQL Server,同时将前端移动到Access 2003(使用Access Data Projects).在此迁移过程中,后端数据结构将发生显着变化,以支持新功能.
如果我有我的愿望,我们就不会使用Access作为前端.我认为我们的应用程序可以通过WinForms,WPF或Web应用程序更好地服务.我们有足够的时间来正确规划业务逻辑层并实现一个出色的解决方案,但是我上面的权力希望继续使用Access,因为这是他们熟悉的.
我可以使用的帮助是继续沿着这条Access开发路径的利弊.使用Access 2003有什么合理的论据支持和反对？这是我到目前为止所提出的.
专业访问:
反对访问
也许还有其他问题我不知道支持和反对Access应用程序开发.我试图保持开放的心态,同时努力保持我的理智.
自从.NET发布以来,我一直在使用C#,并且回到VBA六个月的想法让我头疼.特别是当我觉得如果允许用现代语言和工具开发的话我可以提供更多东西？
ADP是围绕ADO Classic(OLEDB的包装器)接口构建的,它是孤立的,不会看到进一步的开发.在A2007和A2010,学术发展中保持不变,这表明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或其他一些完全不同的平台(虽然我从来没有使用学术发展建议或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集成密切相关.知道这一点,你可能会对利弊的相对平衡得出不同的结论.
| 归档时间： |
|
| 查看次数： |
1882 次 |
| 最近记录： |