2011-12-12 9 views
0

它基本上是一个CRUD应用程序。是否有任何Access插件可简化屏幕,报表和SQL存储过程的开发?我不熟悉VBA或宏。我需要能够控制光标移动,执行条件if,输入值前后发生什么,查找表等。但我认为学习曲线需要相当长的一段时间,并且需要时间来加速VBA和宏。我甚至已经听说用VB称为RadVolution的附加软件来开发这个应用程序更好。我实际上宁愿开发这个应用程序作为触摸屏POS风格的应用程序,但没有意识到任何RAD工具或SDK的。我熟悉Informix-SQL和非Visual Basic,但没有C语言或面向对象的语言体验,我是旧学校程序语言(Basic,COBOL)。任何人愿意为这个转换项目工作或帮助我?将使用INFORMIX-SQL编写的应用程序转换为Access 2010,但我不熟悉VBA或Macro的

回答

0

Microsoft Access是非常简单的,因为它是。有形式和报告创建的向导。然后,您可以修改事件以执行您提到的所有任务。

我建议在这个主题上写一本好书并钻研。我从Developer's Handbook系列中了解了很多(几年前),包括Access Developer's HandbookVBA Developer's Handbook

看起来你已经决定将整个系统迁移到MS Access,但你有没有想过用Grails这样的平台首先为你的IDS系统蒙皮?它是跨平台的,可以部署在任何支持Java的操作系统上。

根据客户的要求,您可以将生成的应用程序部署为单个用户,单个站点或共享系统。

迁移并增强了所有现有功能之后,将后端数据库转换为另一个引擎(如PostgreSQL)会很简单。

我目前正在为一个客户端增强一个传统的Informix 7(SE/ACE/4GL)应用程序,它的工作非常好。

+0

我不熟悉OOP,Java或C ..尽管我听说过有关Access的综合评论,但我觉得有必要在Access中使用它,因为它与其他MS-Office模块(每个人都有Office)及其微软相集成。 –

1

Access的真正优势在于其简单性,它被称为“快速应用数据库开发和报告工具”。大多数情况下,如果表单和报表不需要任何VBA,如果看起来很复杂,那很可能是你做错了。唯一的问题是你期望有多少用户以及你期望运行你的应用程序的位置?很多不好的新闻是由于滥用,使用得当,Access可以非常方便。

1

你真的不想要某种类型的自动转换。原因在于您需要更改如何完成这些工作,以适应从一个开发系统迁移到另一个开发系统时发生的体系结构更改。

自动转换可能没有多大价值,因为在新系统中,以前系统中的事情如何完成将会有所不同。例如,当人们从DOS来到基于(文本屏为主)的FoxPro应用程序访问当时有两辆显著变化,开发商不得不做出:

1)在访问

FoxPro中没有记录编号(这是一个与dBase兼容的克隆)起源于一个歌手用户基于文件的数据库系统。所以这是系统设计从根本上在您的个人电脑上运行。这意味着文件和编程系统使用硬盘上文件的顺序记录。这种模式非常像冲卡数据处理。我应该指出这种类型的模型没什么问题,但是与交互式多用户系统相比,用于打卡数据处理的软件方法和设计有些不同。

什么是重要和最重要的这里是一个概念上的水平,当你写访问的内部软件则记录编号或使呼叫记录顺序的概念想法,因为你写的软件是不相关的。然而,在Foxpro中假定记录顺序是一个合理的假设。这是一个架构变化。我记得早在90年代,在很多论坛中,长期以来Foxpro开发人员询问的第一个问题是:

访问权限怎么没有像Foxpro那样的记录数?

答案很简单,并且回答是/是Access认为数据数据的一大巨大的无序桶。换句话说,如果您想要对您的数据进行一些订购,则必须添加一些类似发票号的内容,甚至可能是时间戳或其他内容。对于像子表格这样的普通规则,您可以依赖自动编号,但该编号应该永远不会被用户看到。无论如何,您必须使用SQL查询来确定您想要的顺序。

另一个重要的细节是,如果您向表中添加10条记录(即使在单用户模式下),如果您从该表中检索到这10条记录,则不能假定记录顺序与添加时相同他们。换句话说,如果您需要特定订单,则必须按某个列对数据进行排序。这是一个假设,FoxPpro或使用FORTRAN和打卡的人可以始终假设。使用Access时无法做出这样的假设。事实上,这个假设不能用任何现代的基于服务器的系统如SQL服务器来进行。

然而,这“缺乏”记录顺序的假设是显著重要后来的道路。这个“假设”意味着那么你的整个Access设计现在基于允许容易转换到多用户系统或者客户到服务器的假设(都需要假设)。

所以,你的软件设计也不会说去(根据记录编号),下一首或上创下记录现在记录的喃喃混杂由不同的人被输入。该表格(或以前的表格)中的下两个词汇可能不是您的!因此,请记住,尽管Access允许您转到表单内的下一个/上一个记录,但它绝不会根据记录编号进行,而只会根据当前加载到该表单中的数据进行。在FoxPro中,你通常会使用命令来移动,这个命令会在表中记录4。

在访问我们不说去在表中的第4个记录。你可能会说我们从表格中抽取一些数据到第四条记录,但是第四条记录与表格中的实际物理第四条记录完全无关。一个小小的变化,但是我们在10年后开始使用的多用户系统需要这个变化(所以10年后,软件产生了巨大的变化!)。

作为一般规则,表中记录顺序的体系结构或哲学概念对于您编写的大多数软件来说都不是什么大问题,但如果您稍后需要使用SQL Server,那么它就是大不了。我应该指出,由于您的软件是使用SQL编写的,因此至少在这方面您的状态良好。

然而,对于那些写在应用基于这个简单的记录顺序的假设4〜5年,那就要完全重新architectured用于多用户环境,甚至进行访问。

我应该指出,FoxPpro最终成为了一个辉煌的面向对象的客户端服务器开发工具,但不得不经过比典型的FoxPro应用程序具有的原始架构和设计显着的变态。

2)事件驱动编程

在你倾向于写一个大的主要的启动程序与主菜单系统包括这些旧的基于文本的系统。选择一个菜单选项可能会分支到主程序中的一个部分,或者分支出来并调用另一部分或部分应用程序。然而,FoxPro和许多开发工具的功劳确实有一些事件类型的设置,但它们并不理想。无论如何,放弃基于文本的用户界面时,最好重新做好这些屏幕和用户界面的工作方式 - 这非常适用于新的基于触摸和基于手势的用户界面,现在我们可以看到像智能手机或iPad。

在事件驱动编程,我们作为一个一般的规则没有那么大的启动程序。而且我们也没有用于主菜单系统的大型代码库。在事件驱动的编程中,你有代码响应用户点击。或者你有代码响应记录保存。甚至导航到下一个记录。

所以在事件驱动编程你点击一个按钮,然后代码相当小位将被用户(在这种情况下,鼠标点击)响应事件。所以这种类型的编程就是我们所说的事件驱动编程。

突然间,你的应用程序现在已经不被驱动或者由一个大的大主程序运行,但实际上是一大堆由事件驱动的代码缝合在一起,一点微小的小程序。

对于人们从DOS基础的环境,甚至的QuickBasic,GW-Basic或甚至很多上了年纪的基于文本的数据库系统的到来,然后有一些菜单系统,一个大的启动程序是共同的。

并且有一个大的程序来“编辑”一个数据输入屏幕是很常见的。

现在,这样的设计被颠倒中,你的菜单,然后单击事件现在将要运行和调用的代码。因此,这些非常小的例程会调用其他代码位以允许应用程序运行。

主要原因架构变化是引入鼠标和图形用户界面。换句话说,当查看数据输入表单时,用户现在可以点击许多不同的东西,甚至点击菜单栏,以代替在复杂数据输入表单中的下一个字段的标签。所以他们可以点击表格上的任何地方。这意味着拥有一个运行和维护表单数据条目的大程序是不可能的。如果您的代码正在等待公司字段中的输入,那么当用户单击菜单栏选项时如何运行代码?由于用户可以以许多不同于原始程序员预期的顺序完成许多事情,因此我们需要采用不同的编写代码的方式。

在这一天与GUI末尾,则代码分支变得太复杂,开发人员预期。因此,事件驱动编程的概念诞生了,以解决这个困境。换句话说,我们的代码现在运行并响应用户操作,并且我们的代码不会等待坐在某行代码中的下一个用户输入。

再次,这是一个小结构的变化,但许多开发者在软件开发方法这一概念转变挣扎。另一方面,所有这些变化发生在90年代初。

接下来的大变化是面向对象编程。 Access允许你创建类对象,但它不是一个完整的面向对象系统。

今天,下一个巨大的挑战和变化和体系结构是构建基于Web的系统的能力。由于为开发人员“解决”了不同的程序,再次发生了数十万次的变化。 Access 2010允许我们现在构建基于Web的系统,而这种概念和体系结构的变化比我们用Access开发Web表单所学的新宏语言的挑战要大得多。因此,设计软件的方式必须再次发生“变化”。

我应该指出,这个行业的这些重大变化大约每10年发生一次。

我所有上述的观点是,即使有一些自动转换系统,它的确会不能很好地工作,因为系统的架构有很大的不同。你会被所有旧的假设所妨碍。

我也注意到你一直在到处问有关在各种访问论坛,什么两年左右甚至更多,现在访问使用?你似乎在寻找一些可以解决你的问题的魔法银弹。没有一个!

在这一天结束时,你需要坐下来获得一些基本的存取技能或雇人。你需要学习你要使用的系统,然后提出一个适用于Access的设计方案,以及适用于Access的方案。

我应该是你选择访问与vb.net将没有必要再说工作德兴任指出。所以不要试图采取现有的设计方法,并将方钉放在圆孔中。在用户界面方面在一个系统中起作用的其他系统无法工作。

我觉得你在这儿玩得太久了。关于拖延这么长时间的唯一好处是你现在必须考虑是否要采用一组工具来允许与应用程序进行一些Web集成?

Office 365中的伟大工程与接入网络发布,但对于复杂应用的成熟,我觉得在网络侧是有点弱(但您可以用Access 2010中写的混合应用程序现在)。以下是访问网络的行动中的视频:

http://www.youtube.com/watch?v=AU4mH0jPntI

在上面,我要等维护在Web浏览器中运行的应用程序了。这个应用程序100%内置在Access中,包括表格触发逻辑和代码(没有第三方工具或编码系统被使用 - 仅使用Access)。

考虑技术,现在,也许是因为他们在店里走动你在iPad上运行这个?这里有很多新的软件选择,但是如果你再坐两三年,那么你会用iPad和其他“其他”系统。

您当然可以在Access中将您的应用程序编写为更“亲和”的应用程序。然而,一些新的基于手势的动作不会转移到网络上。例如,我们不能禁用组合框中的键盘输入,并且如果可以的话,这种能力将真正帮助在iPad上运行的Access应用程序。原因是当我们在iPad上点击或击打组合框时,它会在屏幕上弹出软键盘,我们不希望这样。还有一些非常漂亮的手势日期选择器等不能翻译成iPad上的网页(他们确实希望你编写本地应用程序!)。

+0

我基本上有一个基于角色的典当管理应用程序,它已经满足了我23年来的所有用户需求。要求:仅限桌面应用程序,几乎全部为单用户Mom-n-Pop商店,无需存储或显示客户I.D.卡片,指纹,商品图像等(这些物品通过复印机在打印票据的背面(商店副本)上进行实体复制,并且系统跟踪哪些棋子过期,并每天/每周计算利息/兑换付款/每月/每季度/每年总计,政府报告等等。它执行一些ETL到Excel。 –

+0

基于角色的用户界面的整洁的事情是,它强制用户按照预先定义的导航路径输入/更新数据不需要用鼠标四处移动,焦点/点击/类型/焦点/点击,这浪费了很多时间!)然而,一些整洁的东西,如允许动态添加新值的组合框等将是期望的。对于记录的排序,我使用CLUSTERED INDEXES来维护所需记录的顺序,我的应用程序有这么多的功能,条件逻辑,它将永远转换为OOP /事件驱动的体系结构!我停滞了! –

相关问题