我知道这取决于应用程序。有问题的工具在固定宽度的文本文件上进行迭代，并根据Access表中指定的一组验证规则进行检查。使用当前工具，通过所有验证检查运行标准文件可能需要长达一个小时的时间。
我可以将验证规则表迁移到SQL Server中，并将代码重构到一个独立的VB.Net应用程序中。
我有什么理由期望看到性能的提高吗？
它取决于很多事情，尤其是开发人员。我一直认为，一个技术差的好开发者比一个技术先进的差开发者能生产出更好的产品。
在做出迁移的决定时，有许多重要的变量。例如：
- 您当前的数据库是在服务器上运行还是在本地计算机上运行？我曾为那些服务器空间总是不足的大公司工作过。这确实会降低性能。使用大量内存在本地运行总是会更快
- 当您运行这些规则时，这些表是在查询中使用还是在代码中使用？它优化了吗？它是否需要经历许多级别的查询。试着把它们剪掉
- 如果数据库中有很多VBA，请尝试在带有计时器的代码中放入大量debug.print，这样您就可以看到进程的哪些部分运行得很快\很慢
- 有人在数据库运行时访问数据库吗
- 你需要为这些表编制索引吗？有时索引过多会影响性能，尤其是在不需要的情况下
- 也许您可以在导入文件时尝试规范化文件的元素，然后运行规则
- 如果数据库当前没有拆分为前端-后端，请尝试拆分它。也许它太大了(压缩并修复(
正如你在帖子中提到的，有很多变量处于危险之中，所以我不会急于迁移。相信我，我以前见过，如果不仔细分析你的现状，就不能保证你会有显著的进步。
您可以考虑的另一件事是自动化，而不是迁移。我在一个RAD团队工作，该团队在清晨运行了大量流程。我们只是使用Windows计划任务在特定时间启动数据库，搜索和导入文件，然后处理它们。有些流程可能需要一个小时，但它们都是在我们早上进入办公室之前完成的，所以谁在乎它是否需要一小时，只要它完成了。
正如您所说，真正的答案是"取决于…"，但我大胆猜测，根据您所描述的处理类型，在Access VBA中执行此类工作与在独立.NET应用程序中执行相同类型的工作之间不会有太大的性能差异。
将后端数据库从ACE/Jet切换到SQL Server可以产生一些显著的性能优势，这取决于所涉及的数据量以及某些验证是否可以从应用程序级别(VBA或.NET(向下推到数据库级别(SQL Server(。但是，将后端移动到SQL Server并不一定需要将应用程序代码从VBA完全移植到.NET。根据您的具体要求，您可以。。。
- 使用ACE/Jet作为后端的Access VBA工程
- 使用SQL Server作为后端的Access VBA项目(链接表(
- 使用ACE/Jet作为后端的.NET应用程序，或者
- 使用SQL Server作为后端的.NET应用程序
使用.NET提高性能的最佳机会是将规则拉入内存(可能是规则对象的集合(，并从进程中消除数据库瓶颈。
如果您重复从Access表中提取规则，您可能会看到性能改进，但很可能是您执行验证的方式导致了性能问题。NET将使您能够在将文本文件加载到内存后对其进行并行操作，这可能会提高性能。但是，如果您的需求可以跨所有行实现，那么我认为您最大的改进可能是将文本文件中的数据提取到T-SQL中实现的SQL Server中，该SQL Server针对操作整组数据而不是逐行进行优化。或者从外部工具实现它们(是的，.NET将比VBA更快(。
如果您不能/不想将文本文件拉入SQL，请考虑在.NET中，您可以将该文件拉入内存&使用多线程循环操作它，根据您的规则进行测试。当然，线程数量是有限制的，但如果你有4个处理器，你也可以使用它们。