有没有充分的理由继续编写VBA + Access Forms应用程序？

Question

有没有充分的理由继续编写VBA + Access Forms应用程序？

Chr*_*lli 1 ms-access vba legacy-code

我最近被要求更新旧的Access Forms应用程序.来自.NET背景,我发现变化令人恐惧,并且变得有点不舒服.我以为这些都是传统技术,很快变得不合时宜......

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

Answer 1

Dav*_*ton 28

我没有回答问题的潜台词(无论什么内容都是Access应用程序很糟糕),而是提供一些有关Access未来的信息:

Access是Microsoft的旗舰产品.在微软的产品线中没有任何替代品,因此在可预见的未来,它将以某种形式继续由微软推广和开发(只要有来自MS的Office套件,就会有Access).
对于Access提供的功能,MS之外几乎没有竞争.唯一可比的产品是FileMaker Pro.有人可能会说OpenOffice套件中的Base组件是竞争对手,但它只涵盖FM和Access提供的功能的一部分(这并不是说它可能不适用于任何数量的场景).
Access(以及整个Office套件)仍然使用VBA作为其编程语言,其余的Microsoft已经从VB转向基于.NET的语言.其他Office产品现在可以使用.NET组件(尽管与使用VBA的方式不同),但Access不是这种情况.我希望在接下来的几个版本的Access(不是在A2010)中的某个时候,.NET支持将以某种方式引入.但是,了解MS的历史,VBA将继续支持多个版本.
历史上,访问应用程序在Web部署方面存在巨大的弱点,这是FileMaker多年前提供的.A2010通过Sharepoint集成纠正了那么大的时间,允许使用可以在Access客户端和Web浏览器中运行相同的新Web对象创建Access应用程序(任何符合标准的Web浏览器 - 不再需要Web组件和限制IE).
尽管MS使Jet 4成为Windows操作系统的一个组成部分(现在仍然如此),但Jet数据库引擎基本上已被宣布为Jet 4(即1999年发布)宣布死亡.随着Access 2007的发布,Jet获得了新的生命,并且包含了一个名为ACE的新版Jet数据库引擎,并由Access开发团队拥有(Jet 4继续归Windows开发团队所有,并且被冻结为,没有额外的发展).ACE中引入的大部分新功能都是由Microsoft将Access与Sharepoint集成的目标所驱动的,但是对于A2010,一些新功能(如表级数据宏,可以实现等效的触发器)即使没有使用Sharepoint(其他人,如多值字段,不是).对于64位版本的Office,现在有一个64位版本的ACE,因此Jet/ACE现在可以在64位应用程序中使用,而无需仅编译为32位.

现在,最后一个问题:

@ChrisDiRulli问:

是否有任何理由继续使用这项技术(除了避免移动它的成本)？

当然,有充分的理由继续使用Access:

该应用程序已经开发.
该应用程序工作,或运作良好,以完成工作.
该应用程序只需要一些新功能,而不是完全重写.
该应用程序由一组没有部署问题的用户使用(它们都具有完全Access或正在使用运行时).

在我看来,Access有一个美好的未来.自从Office 95/97发布以来,我一直对Access充满热情,Office 95/97将VBA引入Office套件并启用了在Office套件之上构建的"元应用程序".

现在在任何特定的情况下,使用传统的Access应用程序,问题可能是没有人知道如何修复现有的应用程序,或者现有的应用程序是意大利面条代码和宏的混乱(更糟糕的是如果它使用宏,因为它是几乎不可能告诉他们如何相互关联),或者架构是坏的,或者,或者......

如果问题在于没有人可以拯救应用程序(或兴趣),那么您应该考虑聘请一位经验丰富的Access开发人员.找到那些人不是那么简单,但那里有很多人.您可以通过他们在Access Usenet组中的公开帖子来判断谁是合格的人,甚至可以在SO上公布其中的一些人.

如果您不想这样做,您可能会花费更多的钱,或者试图弄清楚如何修复Access应用程序,或者发现在Access之外复制相同功能的成本是多么昂贵.在后一种情况下,许多组织选择将应用程序替换为仅提供相同功能的一小部分的应用程序.这是疏远最终用户并将其推向预订方向并且未来不向IT寻求帮助的好方法,所以这可能不是一个好主意.

但首先要做的事情是:

失去对Access的敌意.这是非理性的,99.99%可能完全基于无知.

@ChrisDiRulli:我觉得你不想让自己看起来不那么傻.至于版本控制,谷歌是你的朋友.也就是说,我认为Access最适合一次只能由一个开发人员管理的项目. (4认同)
O_o的+1:D非常好写和周到. (3认同)
对不起,我发了一个认真的答复.你不配得到这里的帮助. (3认同)
你是对的!访问和VBA很热!现在,让我继续下载该修补程序,以便鼠标滚轮事件在VB6 IDE中工作http://support.microsoft.com/kb/837910什么是一堆垃圾.BTW,关注版本控制吗？不这么认为. (2认同)
噗！这个答案很火！我喜欢“50 岁的恐龙”这一论点，因为它确实反映了其作者的年轻。@ChrisDiRulli，我还没有使用 vb.net 开发客户端应用程序，其中包括 220 多个表单、超过 500 个不同的菜单选项、所有可以帮助用户（报告集成、导出功能等）并允许开发人员制作的好东西智能（事务跟进、错误跟踪、版本比较、自动更新程序等），但我是用 Access 完成的。它快速、干净、简单。它有效... (2认同)
"几乎没有资源"？您知道,作为Office 2010部署的一部分,他们已将VBA移植到64位运行,并添加了适当的数据类型和其他调整以使其工作？(http://msdn.microsoft.com/en-us/library/ee691831(office.14).aspx)这对我来说并不像"没有资源".当你发布原始问题时,你的肩膀上有一块芯片,你已经证明你并没有真正得到你在这里收到的质量答案. (2认同)
@ChrisDiRulli Ooof我知道这是一个旧线程,但有一件事,VB.Net默认不做懒惰评估 - 你必须使用`AndAlso`或`OrElse`来强制短路.只是在说'.哦,并且以你的方式谴责大卫的非常完整和有效的答案是粗鲁的,而不是在SO的精神. (2认同)

Answer 2

Eri*_* J. 9

仍然有大量用COBOL编写的软件,这比Access早得多.

在某些领域,Access应用程序可能足够且成本最低.如果它完成了工作(你的工作部分是让你的雇主知道它是否真的完成了工作),如果这是他们想要的,那就去吧.

如果你看到一个很好的理由说.NET项目会更好或者Access会出现问题,那就公开讨论它们,并尝试做出一个符合削减支票的人的最佳利益的决定.

归档时间：	15 年，11 月前
查看次数：	1874 次
最近记录：	15 年，11 月前