需要数据库建议：将 VB6/ADO/JET 应用程序移植到 VB.NET答案

【问题标题】：Database advice needed: porting VB6/ADO/JET app to VB.NET需要数据库建议：将 VB6/ADO/JET 应用程序移植到 VB.NET
【发布时间】：2011-03-19 11:12:27
【问题描述】：

我需要在 Visual Studio 2008 中将一个使用 ADO 访问 JET 数据库的小型 VB6 应用程序更新（好吧，真的重写）到一个 vb.net 应用程序。

我的研究表明我应该使用 LINQ，但似乎无法连接到 JET。如果现在不推荐使用 JET，我应该使用什么？或者我应该在没有 LINQ 的情况下使用 ADO.NET？

请不要回答 SQL Server！ - 这需要是最终用户可以在公司或非公司环境中轻松安装的应用程序，并且不得需要任何持续的技术维护。我开始安装 SQL Express，但当它需要至少 2 次系统更新时就停止了，因为这对于这个小应用程序来说太复杂了。

【问题讨论】：

你在更新什么，供你使用.net？我知道，应该升级工具/技术。它的商业原因是什么？
@shahkalpesh：我不知道他的原因，但我知道许多客户在发现 MS 不再支持 VB6 应用程序时会担心它（即使他们从未使用过支持，它仍然让每个人都感觉更好）。
原因仅仅是我被指示将所有 VB6 应用程序移植到 .NET！
或许值得问问决策者为什么他们决定移植到 .Net。 VB6 运行时是所有当前 Windows 版本的一部分，完全支持msdn.microsoft.com/en-us/vbasic/ms788708.aspx。同样，Jet 引擎是所有当前 Windows 版本的一部分，并且完全受支持。显然，移植到 .Net 有很多充分的理由，但不要因为您认为 VB6 不再受支持而冲入它。移植不需要更改或扩展的工作 VB6 应用程序的紧迫性较低。
VB6 IDE 是否在 2008 年 4 月 8 日停止工作？

标签： vb.net linq ado jet vb6-migration

【解决方案1】：

Jet 已被弃用，但有一个 ACE（Access Database Engine）形式的替代品。

但是，关于从 LINQ 使用它。这个question 的答案有各种建议，我也在某处读到可能使用LINQ to DataSet 来做到这一点。这是一篇关于它的博客文章：Querying DataSets – Introduction to LINQ to DataSet 但我找不到指向我读到有人成功使用它访问 Access DB 的链接。

不过我建议，如果没有明确的解决方案来使用 LINQ，务实的方法是坚持使用普通的 ADO.Net 并等待使用 LINQ，直到您确定您使用的是完全支持它的数据源。

【讨论】：

ACE 的替代品有多接近？在运行 XP 的客户端上安装会不会出现问题？
@SM：我不确定我害怕。我的理解是，它是由 Office 团队在 Jet 被弃用时开发的，并且应该与 Jet 完全向后兼容，但如果与 .accdb 文件而不是 .mdb 文件一起使用，它会包含一些新功能。自从它与 Office 2007 一起推出以来，我相当肯定它可以在 XP 上正常工作。
Jet 尚未被弃用。时期。声明结束。 MS 一直在为其旗舰开发工具推荐不同的技术，但这更多的是从 VB 到 .NET 语言的过渡，而不是与 Jet/ACE 的未来有关。
ACE 不是 Jet 的替代品——它是 Jet，只是它的下一个版本的新名称。 Jet 4 作为 Windows 的一部分保持冻结状态，ACE 不会像 Jet 4 那样并入 Windows。
您引用的 URL 是我已经提到的一个完美示例，即过渡到 .NET 导致 MS 推荐不同的数据库技术。 Jet 在这种情况下可能会被弃用，但在许多其他情况下它仍然存在并且运行良好。您在 64 位和缺乏开发方面是错误的。 Jet 4 被冻结，但不是 Jet 数据库引擎——它现在只是称为 ACE。如果你指的是 Jet 4，那么就说 Jet 4，但你必须意识到，当你这样做时，你所做的陈述远没有你原来的断言那么笼统。

【解决方案2】：

如果您的项目包含少于 10000 行代码，这是一个免费的好升级工具：
http://msdn.microsoft.com/en-us/vbasic/ff793478.aspx

您应该遵循的一般方法是，首先从 VB6 到 VB.NET 的干净迁移，让 .NET 版本完全像在 VB6 中一样工作，然后开始寻找 .NET 中的替代技术。当您有一个工作的 .NET 应用程序时，在不同技术之间进行转换比手动尝试直接从 VB6 代码转换为 .NET 中的替代方案更容易。

这里有一些很好的理由先迁移而不是手动重写：
5 myth busting reasons for choosing automatic migration vs manual rewrite

来自文章：

即使在最坏的情况下，您仍然需要在自动迁移阶段之后重写应用程序的某个部分，最终结果将始终只是总成本和时间的一小部分。

【讨论】：

我不同意您建议的方法，但是一旦移植，它将永远不会被重写为更“正确”的 vb.net。这确实是使用更新的方法重写应用程序的唯一机会。
你可能会花更少的时间遵循这种方法，只是不要告诉你的老板它是在转换后重写之前转换的......
感谢您提供升级工具的链接。 VS 自动升级给我们留下了深刻的印象，但我会试一试。
一句忠告。除非应用程序非常小，否则请谨慎使用更新的方法进行重写。在重写过程中陷入困境是一个常见的陷阱——这就是你的老板对你不满意的时候。
cf：网景上的斯波尔斯基：joelonsoftware.com/articles/fog0000000069.html

【解决方案3】：

只需使用 OleDbConnection / OleDbCommand / OleDbDataReader 对象来模仿您在 VB6/ADO 代码中的相同逻辑。它将以相同的方式工作，并且不需要比现有应用更多的依赖项。

【讨论】：

所以你认为我应该继续使用 JET？
是的。 JET 不会突然停止工作，因为您已经用不同的语言重新编写了客户端代码。 JET 是否真的存在于您的目标机器上取决于您的安装程序。这是您在部署 VB6 代码时已经解决的问题。
Jet 4 存在于从 Windows 2000 开始的所有 Windows 版本上。 64 位的情况更加模糊——我不确定 64 位版本的 Windows 为 Jet 用于（Active Directory）的目的做了什么，或者 64 位版本的 Access（2010）是否提供 64位 ACE 和 64 位 Jet。后者对我来说似乎不太可能，但我看不出他们如何在不支持 MDB 文件的情况下提供 64 位访问，所以他们必须创建 64 位版本的 Jet（据我所知，A2007 和 A2010 可以不使用 ACE 与 MDB 交互，而是使用 Jet 4；例如，参见 DAO 引用）。

【解决方案4】：

这些可能是有趣的：

Which O/RM tool supports Microsofts Access? http://blogs.msdn.com/b/adonet/archive/2007/01/26/querying-datasets-introduction-to-linq-to-dataset.aspx

【讨论】：