它基本上是一个 CRUD 应用程序。是否有任何 Access 插件来简化屏幕、报告、SQL 存储过程的开发？我不熟悉 VBA 或宏。我需要能够控制光标移动、执行条件 if、输入值之前或之后发生的情况、表格查找等。
我已经对 Access 进行了修改，已经定义了架构和关系，但我想学习曲线将需要相当长的时间，并且听说需要时间来加快 VBA 和宏的速度。我什至听说过它更好使用名为 RadVolution 的 VB 插件开发此应用程序。实际上，我宁愿将此应用程序开发为触摸屏 POS 风格的应用程序，但不知道为此有任何 RAD 工具或 SDK。我熟悉 Informix-SQL 和非可视化 Basic，但没有 C 或面向对象的语言经验，我是老派过程语言（Basic、COBOL）。任何愿意工作或帮助我完成这个转换项目的人?
无论如何，您真的不想要某种类型的自动转换。原因是你需要改变你做这些事情的方式，以适应从一个开发系统转移到另一个开发系统时发生的架构变化。
自动转换可能并不值得，因为在以前的系统中完成的事情通常在新系统中会以不同的方式完成。例如，当人们从基于 DOS（基于文本屏幕）的 FoxPro 应用程序转到 Access 时，开发人员必须进行两项重大更改：
1）Access中没有记录号
FoxPro（它是与 dBase 兼容的克隆）起源于基于歌手用户文件的数据库系统。所以这是从头开始设计的系统，可以在您的个人计算机上运行。这意味着文件和编程系统使用硬盘驱动器上文件的顺序记录。这个模型很像打孔卡数据处理。我应该指出，这种模型没有任何问题，但是与交互式多用户系统相比，您用于打卡数据处理的软件方法和设计有些不同。
当您在 Access 中编写软件然后记录数字或称为记录顺序时，重要且最重要的是概念级别，因为您编写软件时不相关。然而，在 Foxpro 中，假设记录顺序是一个合理的假设。这是架构变化。我记得早在 90 年代初期，在许多论坛中，Foxpro 长期开发人员提出的第一个问题是：
为什么 access 没有 Foxpro 那样的记录号码？
答案很简单，答案是/曾经是 Access 认为数据是一个巨大的无序数据桶。换句话说，如果您想对数据进行排序，则必须添加诸如发票编号之类的内容，甚至可能是时间戳或其他内容。对于像子表单这样的一般规则，您可以依赖自动编号，但用户永远不会看到该自动编号。无论如何，您必须使用 SQL 查询来说明您想要什么顺序。
另一个重要的细节是，如果您将 10 条记录添加到表中（即使在单用户模式下），如果您随后从该表中检索这 10 条记录，您不能假设记录顺序与添加它们时相同。换句话说，如果您需要特定的顺序，则必须按某列对该数据进行排序。这是 FoxPpro 或使用 FORTRAN 和打孔卡的人总是可以假设的假设。使用 Access 时无法做出此类假设。事实上，对于任何基于现代服务器的系统（例如 SQL 服务器）都无法做出这种假设。
然而，这种“缺乏”记录订单假设在以后的道路上非常重要。这个“假设”意味着您的整个访问设计现在基于允许轻松转换为多用户系统或客户端到服务器的假设（两者都需要这个假设）。
因此，您的软件设计永远不会说转到下一个或上一个记录（基于记录编号），因为记录现在是由不同人输入的杂乱无章的记录。该表中接下来的两个记录（或以前的记录）可能不是您的！所以请记住，虽然 Access 允许您转到表单内的下一条/上一条记录，但它从不基于记录号，而仅基于当前加载到该表单中的数据。在 FoxPro 中，您通常会通过实际使用命令转到表中的记录 4 来移动。
在 Access 中，我们不会说转到表中的第 4 条记录。您可能会说我们从表格中提取到表格中的某些数据中的第 4 条记录，但第 4 条记录与表格中实际的物理第四条记录完全无关。一个很小的变化，但对于我们 10 年后开始使用的多用户系统来说是必需的（所以软件的微小变化在 10 年后产生了好处！）。
作为一般规则，这种架构或表中记录顺序的哲学概念对于您编写的大多数软件来说根本不是什么大问题，但如果您以后需要使用 SQL 服务器，那就大不了了。我应该指出，既然你的软件是使用 SQL 编写的，那么至少在这方面你的状态很好。
然而，对于那些基于这个简单的记录顺序假设在 4 到 5 年内编写应用程序的人来说，它必须是针对多用户环境甚至 Access 的完全 RE 架构。
我应该指出，FoxPpro 最终成为了一个出色的面向对象的客户端服务器开发工具，但与典型 FoxPro 应用程序所具有的原始架构和设计相比，它必须经历一个重大的蜕变。
2) 事件驱动编程
在这些较旧的基于文本的系统中，您倾向于编写一个包含主菜单系统的大型主要启动程序。选择一个菜单选项然后可能会分支到主程序中的一个部分，或者可能分支出来并调用应用程序的另一部分或一部分。然而值得称赞的是，FoxPro 和大量开发工具确实有一些事件类型的设置，但它们并不理想。无论如何，在删除基于文本的 UI 时，最好重新执行这些屏幕和 UI 的大部分工作方式——这对于我们现在看到的新的基于触摸和基于手势的 UI（例如智能手机或 iPad）来说非常重要。
在事件驱动编程中，我们通常没有那么大的启动程序。而且我们也没有用于主菜单系统的大型代码库。在事件驱动编程中，您有响应用户点击的代码。或者您有响应记录保存的代码。甚至导航到下一条记录。
因此，在事件驱动编程中，您单击一个按钮，然后一小段代码将响应用户的事件（在本例中为鼠标单击）。所以这种类型的编程就是我们所说的事件驱动编程。
突然之间，您的应用程序现在不是由一个大型主程序驱动或运行，而是实际上是由事件驱动代码拼接在一起的一大堆小程序。
对于来自基于 DOS 的环境，甚至 QuickBasic、GW-basic 甚至许多旧的基于文本的数据库系统的人来说，拥有一个带有一些菜单系统的大型启动程序是很常见的。
并且有一个大型程序来“编辑”一个数据输入屏幕是很常见的。
现在这样的设计被颠倒了，您的菜单和点击事件现在将运行并调用代码。因此，这些非常小的例程将调用其他代码位以允许应用程序运行。
这种架构变化的主要原因是鼠标和图形用户界面的引入。换句话说，当查看数据输入表单时，用户现在可以点击许多不同的东西，甚至点击菜单栏，而不是在复杂的数据输入表单中跳到下一个字段。所以他们可以点击表格上的任何地方。这意味着拥有一个大程序来运行和维护表单数据输入是/不可能的。如果您的代码正在等待公司字段中的输入，那么当用户单击菜单栏选项时如何运行代码？由于用户可以按照与原始程序员预期不同的顺序执行许多操作，因此我们需要一种不同的代码编写方式。
在一天结束时使用 GUI，代码分支变得过于复杂，开发人员无法预料。因此，事件驱动编程的概念应运而生，以解决这一难题。换句话说，我们的代码现在运行并响应用户的操作，并且我们的代码不等待位于某行代码中的下一个用户输入。
同样，这是一个小的架构更改，但许多开发人员都在为软件开发方法的这种概念性更改而苦苦挣扎。另一方面，所有这些变化都发生在 90 年代初期。
课程的下一个重大变化是面向对象编程。Access 确实允许您构建类对象，但它不是一个完整的 OO 系统。
今天，下一个重大挑战、变革和架构是构建基于 Web 的系统的能力。由于为开发人员“解决”了不同的程序，再次发生了无数的变化。现在，Access 2010 允许人们构建基于 Web 的系统，而这种概念和体系结构的变化比学习使用 Access 开发 Web 表单的新宏语言更具挑战。因此，您设计软件的方式必须再次发生“变化”。
我应该指出，行业的这些重大变化大约每 10 年左右发生一次。
我的观点是，即使有一些自动转换系统，它也不会很好地工作，因为系统的架构非常不同。你会受到所有旧假设的阻碍。
我还注意到您在各种 Access 论坛中询问使用 Access 已经有两年甚至更长时间了？您似乎正在寻找一些可以解决您的问题的神奇银弹。没有一个！
在一天结束时，您需要坐下来获得一些基本的访问技能或雇用某人。你需要学习你将要使用的系统，然后想出一个与 Access 一起工作的设计，并为 Access 提供“是”。
我应该指出，您为 Access 选择的设计也不必说与 vb.net 一起使用。因此，不要尝试使用现有设计并将方形钉子放入圆孔中。就 UI 而言在一个系统中有效的方法在其他系统中无效。
我想你在这里鬼混太久了。延迟这么久的唯一好处是您现在必须考虑是否要采用一组允许与应用程序进行一些 Web 集成的工具？
Office 365 配合Access web 发布效果很好，但是对于复杂的成熟应用，我觉得web 端有些薄弱（不过现在可以用Access 2010 编写混合应用了）。以下是 Access web in Action 的视频：
http://www.youtube.com/watch?v=AU4mH0jPntI
在上面，我切换到在 Web 浏览器中运行应用程序。该应用程序 100% 内置于 Access，包括表触发逻辑和代码（未使用第 3 方工具或编码系统 - 仅使用 Access）。
考虑到现在的技术，也许当 iPad 在商店里走来走去时，你会在 iPad 上运行？这里有很多新的软件选择，但如果你再坐 2 到 3 年，那么你会寻求使用除 iPad 和“其他”新系统之外的其他东西。
您当然可以在 Access 中编写更“触摸”友好的应用程序。然而，一些新的基于手势的动作不会转移到网络上。例如，我们不能在组合框中禁用键盘输入，如果可以的话，这种能力将真正帮助在 iPad 上运行的 Access 应用程序。原因是当我们点击或点击 iPad 上的组合框时，它会在屏幕上弹出软键盘，我们不希望这样。并且一些非常漂亮的手势日期选择器等不会在 iPad 上转换为网络（毕竟他们确实希望您编写本机应用程序！）。
Access 的真正优势在于其简单性，它被描述为“快速应用程序数据库开发和报告工具”。在大多数情况下，您不需要任何用于表单和报告的 VBA，如果它看起来很复杂，则很可能您做错了什么。唯一的问题是您希望拥有多少用户以及您希望在哪里运行您的应用程序？很多不好的新闻是由于误用，使用得当，Access 确实非常方便。
Microsoft Access 非常简单。有用于创建表单和报告的向导。然后，您可以修改事件以执行您提到的所有任务。
我建议买一本关于这个主题的好书并深入研究。我从开发人员手册系列中学到了很多东西（几年前），包括Access 开发人员手册和VBA 开发人员手册。
看来您已经决定将整个系统迁移到 MS Access，但您有没有想过首先使用Grails之类的平台为您的IDS系统设置皮肤？它是跨平台的，可以部署在任何支持 Java 的操作系统上。
您可以根据客户的要求将生成的应用程序部署为单个用户、单个站点或共享系统。
一旦您迁移并增强了所有现有功能，将后端数据库转换为另一个引擎（如PostgreSQL ）将是微不足道的。
我目前正在为客户增强旧版 Informix 7 (SE/ACE/4GL) 应用程序，并且效果非常好。