我们有一个 12 岁的 Ms Access 应用程序，用于我们的核心库存仓储和发票系统。它已经在 SQL Server 后端运行，但所有“逻辑”、表单和报告都在 Access 中。在经历了将库存交易从非临时性转变为临时性所花费的大量维护污泥之后，我意识到有一天我需要将这个东西转换为代码，这样我才能在一个更易于维护和可测试的环境中更好地管理逻辑。
有哪些技术可以让我以可管理和有效的方式将其转换为 .Net 应用程序？
一个想法是将查询转换为存储过程，然后将应用程序转换为 Adp 项目。但我仍然对如何处理表单和报告一无所知。
此外，如果这很重要，我是我公司唯一的开发人员。
简短的回答：迁移似乎并不容易自动化。
我的猜测是，您最好的选择是一次重写（并安装）系统，即使（可能）它会迫使您的用户并排运行旧版本和新版本一段时间以使用不同的位的功能。您可以通过仔细考虑要迁移的功能以及迁移顺序来最大程度地减少麻烦。
例如，您可能有一位用户，其工作角色要求他或她整天只使用一个屏幕。如果您首先迁移带有附带功能的屏幕，则该用户可以立即进入新系统并留下旧系统，从而减少您的维护负担。
所以这些只是基于没有太多信息的一些想法。无论如何，我希望这会有所帮助。
由于您已经拥有带有一些业务逻辑的 asp.net，因此您可以将其打开以作为 Web 服务（asmx 文件）访问。Google for the Microsoft Office Web Services Toolkit for your version of access (xp/2003 etc.) 这将为您编写 vba 代理类来调用 Web 服务。您可以通过代码（vba 读取和写入控件）将 Web 服务数据绑定到表单，或者使用来自 Web 服务的数据创建本地临时表并使用常规访问绑定。
根据您最熟悉的内容（代码/tsql），您可以将逻辑放入存储过程或业务逻辑层或混合（两者）中。我发现测试代码比存储过程更容易，并且喜欢不绑定到 sql server 的业务逻辑，即如果你想更改数据库或想在没有数据库的情况下离线开发/测试组件。新的 .net 功能（如 LINQ）具有相当好的性能，因此您不必依赖存储过程来进行数据库活动。
保留访问前端用户界面，直到您重构了对 Web 服务的所有业务逻辑/数据访问。然后，您可以根据需要创建一个使用 Web 服务的 asp.net 应用程序或一个 winform 应用程序。（暂时不要使用 wpf，作为 ui，因为它是一个陡峭的学习曲线，并且还没有可以与访问数据表视图进行比较的数据网格。）
报告
访问报告可以升级为sql server 报告服务（报告中的vba不会升级，最好在存储过程中编写一些tsql）。如果您没有完整的 sql server 产品，您仍然可以使用 reportviewer 控件在 asp.net（或标准版本的 winform 或Visual Studio) 绑定到 ado.net 数据集。
其他选项： 您可以编写 .net dll 并使用 com 互操作。这种方法允许您逐渐开始编写功能。不要使用 .net ui，例如 winform，因为它不能很好地与 access ui 配合使用。您可以编写业务逻辑或数据访问逻辑，然后从 vba 调用这些类。然后，如果需要，您可以将此代码移至 asp.net 或 Web 服务。
要排除的事情：
我不喜欢使用并排版本编写新应用程序的方法。作为一个单一的开发人员，你有足够的担心。您最终可能会在两个版本中添加功能并调试两个版本而不是一个版本。
vb6 表单互操作不适用于访问。
如上所述的ADP已经死了。（我从不喜欢它们，因为我经常使用本地表来优化性能，它们只能通过代码调用而不是链接）
您可能能够使用 Visual Basic 升级向导（在 Visual Studio 中）将您的 vba 模块和类模块转换为 vb.net，但它不会放大所有内容（例如，dao/ado 代码到 ado.net 代码）并且不会创建针对 .net 优化的代码，并且可能不容易编写单元测试，具体取决于 vba 代码的设计。我建议重写代码（如果您对测试很认真，请尝试测试驱动开发，看看您是否喜欢它）。
我会考虑查看Interop Forms Toolkit。据我了解，这个工具使得在 VB6 中使用 .NET 表单变得非常容易，所以也许它也可以在 Microsoft Access 中使用？如果是这样，它可能会帮助您以增量方式将应用程序迁移到 .NET。快速搜索后，我找不到任何关于将它与 Microsoft Access 一起使用的指南，因此如果结果证明这是一条死胡同，我深表歉意。
从长远来看，转换为 adp 并不是一个好的解决方案——这项技术已被微软抛弃。
如果你想切换到.net（为什么？你有理由偏爱.net吗？）我建议你开始阅读，尝试创建一些简单的应用程序，然后开始将这个数据库转换为应用程序的任务。
但...
我认为你和公司需要考虑这个项目所涉及的风险。如果您生病了，就在管理层需要一些尚不存在的报告的那一周，会发生什么？我建议你找一家本地的小型软件开发公司，他们会很乐意帮助你的。也许您可以安排您继续担任“首席开发人员”并仅将它们用作备份。
我有一个类似的问题，并通过在 Access 前端创建版本化部署系统（抓取并提取 CAB 文件）来解决它，找出所需的 AppDomain 操作以便能够将正确的 CLR 版本加载到 Access 进程中，加载.config 文件，并以两种方式发布数据。
它使用标准的 C DLL 调用，因此不需要 COM 注册，但遗憾的是不支持 Unicode。
发送命令 - 通用，我可以用这个做所有事情。Open Form - 旨在成为 DoCmd.OpenForm 的“直接”替代品 Open Report - 旨在成为 DoCmd.OpenReport 的“直接”替代品
所以制作一个新的报表，或者将现有的报表迁移到SSRS，制定格式标准，然后在Access中将DoCmd.OpenReport更改为netDoCmd.OpenReport。
遵循命名约定以了解从何处加载报告，以及提取报告所需数据的标准方法。
现在，我正在迁移一个表单或报告，如果容量允许，或者需要对其进行更改。
因为谁能一举阻止功能开发一年？
MDI 不能正常工作。我认为围绕 SetParent 和 UPDATE_UISTYLE 我还需要做一些工作
所有这些都使 UI 处于进程中并在带有 Access 的窗口中。我在 DLL 中构建所有内容，最后一步是创建一个加载“第一个表单”的 EXE，并使用它来替换 Access 前端。