提问人：BobbyOpt 提问时间：7/7/2023 更新时间：7/10/2023 访问量：130
同时在 VB.net 中将 ADODB 记录集与 MS Access 和 MariaDB 一起使用
Using ADODB recordsets with both MS Access and MariaDB in VB.net simultaneously
问：
我们有一个基于 .net 3.5（目前使用 Visual Studio 2019 v16.11 维护）构建的非常大的内部 Visual Basic Windows 窗体应用程序，它将数据存储在一个非常大 （>1GB） 的旧 MS Access“mdb”扩展文件中。我们希望最终将这些数据完全存储在MariaDB（MySQL）数据库中，并取消MS Access文件。该应用程序通过 ADODB 记录集处理表，并使用记录集方法和属性来读取和修改数据，其中更简单的 SQL 语句可能就足够了，甚至是更好的做法。但是，将代码更改为不使用记录集不是一种选择，因为有超过 190,000 行代码 - 必须继续使用 ADODB 记录集。
我们希望该应用程序以与记录集相同的方式同时处理旧的 MS Access 和新的 MariaDB 数据库。这样，我们可以逐步将表“移动”到MariaDB，并逐个解决可能发生的任何问题。
问题是，在执行以下代码以使用MariaDB时：
cnMariaDB = New ADODB.Connection
cnMariaDB.ConnectionString =
"DRIVER={MySQL ODBC 8.0 ANSI Driver};" _
& "Port=3306;" _
& "SERVER=192.1.2.3;" _
& "DATABASE=XYZDatabase;" _
& "UID=XYZUser;PWD=XYZPswd; OPTION=3"
cnMariaDB.Open()
在“cnMariaDB.Open（）”处引发异常：{“[Microsoft][ODBC 驱动程序管理器] 找不到数据源名称且未指定默认驱动程序”} System.Runtime.InteropServices.COMException
如果我将“目标 CPU”从“x86”更改为“AnyCPU”，则上述代码有效或至少没有明确错误。但是，使用MS Access文件的旧代码：
cnRDM = New ADODB.Connection
cnRDM.Provider = "Microsoft.ACE.OLEDB.12.0"
cnRDM.Properties("Data Source").Value = "J:\XYZData.mdb"
cnRDM.Properties("Jet OLEDB:Database Password").Value = "XYZsecret"
cnRDM.Open()
给出此异常：{“找不到提供程序。它可能没有正确安装。System.Runtime.InteropServices.COMException
这两个代码块的执行顺序没有区别。同样，如果我将目标 CPU 设置为 AnyCPU，打开 MariaDB 连接（似乎）可以工作，但打开 MS Access 连接会失败，如果目标 CPU 设置为 x86，反之亦然。
到目前为止，我尝试过： - 不同的框架：3.5 和 4.7（顺便说一句，我没有将现有项目转换为 4.7，而是尝试了一个小型“测试”VB 项目） -在MariaDB连接字符串中尝试了'DRIVER={MySQL ODBC 3.51 Driver}'。 -尝试了 2 个不同的 ADODB.dll 文件，7.10.3077 和
到目前为止我还没有尝试过：
- 升级到 Visual Studio '22（版本
- MariaDB 连接字符串中的不同“OPTION”
任何帮助将不胜感激
答：
0赞
Albert D. Kallal
7/10/2023
#1
如果我将“目标 CPU”从“x86”更改为“AnyCPU”，则上述代码有效或至少没有明确错误。
好的，你必须解决这个问题。VS2019 有 2 个版本，一个是 x32 位版本，一个是 x64 位版本。因此，您必须检查是否运行x64位版本的vs2019。
你实际上必须解决这个问题。基于与任何 cpu 一起使用的糖果的猜测？
这表明您的 MySQL/MariaDB 驱动程序仅为 x64 位，但用于访问的驱动程序（ACE 数据引擎）为 x32 位。
那么，无论哪种方式？您确实需要始终强制项目以“已知”位大小运行。
在 vs2022 中，由于它现在是 x64 位产品（默认情况下），因此任何 CPU 都会导致 x64 位“正在处理”正在运行的应用程序。
在早期版本的 vs 中，任何 CPU 都会生成 x32 位运行的应用程序。
这里的例外是 vs2019，因为它有 2 种口味。
不管任何 CPU 的“潜在”令人困惑的问题？
我建议因为这里涉及ms-access数据引擎？
您必须始终强制项目的位大小。选择 x64 还是 x86（x32 位）并不重要，但您需要修复并强制执行此问题。
因此，您要么：
安装 x64 位 Maria db 驱动程序。或者将 ms-access ACE 驱动程序作为 x64 位。
或者，安装 x32 位 Maria db 驱动程序，然后安装 + 使用 x32 （x86） 版本的 Access“ACE”引擎。
从您的帖子中，我最好的猜测是您没有安装其驱动程序的 Maria x32 位版本。
您也不会注意到此应用程序的任何移动部分是否意味着正在运行某些 ms-access 应用程序，或者 vb.net 应用程序仅使用 ms-access 数据库，并且此处未使用 ms-access 作为产品/应用程序。
因此，您可以安装 ms-acess 运行时，也可以仅安装 ACE 数据库引擎。就您的情况而言，“后者”可能是可以的。
最后但同样重要的？
由于这是一个“mdb”文件，因此您可以承诺使用较旧的 JET 数据库引擎 该数据引擎（JET 而不是 ACE）相当传统，只有 x32 位风格，可以打开“mdb”文件，但无法打开较新的 accDB 文件格式（您需要 ACE 数据引擎）。
为什么要考虑和使用 JET 数据引擎而不是 ACE？
好吧，自从大约 Windows 98 - 很久以前，Windows 操作系统默认包含 JET 的副本。即使是新版本的 Windows 11，甚至是全新的 Windows 服务器版本也包括 JET 数据引擎，并且从 Windows 98 到今天的所有“操作系统”安装都包括 JET 引擎。
因此，您可以“确定”目标计算机，甚至是您现有的计算机，而无需安装任何其他软件，它可以并且将使用和打开 mdb 文件，并且无需安装任何其他软件即可这样做。
但是，要使软件正常工作，必须强制以 x32 位的形式运行 .net 项目。这也意味着您可以继续将连接字符串与“JET”一起使用，而不必在这些连接字符串中使用“ACE”数据引擎。
那么，长话短说？
看起来您没有安装 x32 位版本的 Maria/MySQL 驱动程序。
安装该驱动程序，然后可以放心地将项目强制使用 x32 （x86）。由于取决于 VS 的版本和您的计算机设置，使用任何 CPU 意味着从计算机到计算机，以及从 VS 版本到更高版本，因此您不知道在按 F5 运行时是否得到 x32 位“进程内”正在运行的程序，还是 x64 位“进程内”正在运行的程序。
实际上，我是说您希望将项目强制为给定的位大小，并在开发和部署期间始终这样做。
最后但同样重要的？
既然你很需要，或者在某个时间点用ms-access打开数据库？（也许是紧凑+维修，改变桌子设计等）？我会考虑在某个时间点切换到使用 accDB 文件格式，因为最新版本的 office/Access 的某些版本现在在阅读和使用非常旧的“mdb”文件格式时遇到了困难。
但是，就目前而言，如果 JET 连接打开了 mdb 文件，则暂时坚持使用该文件。
评论