我们有一个非常大的内部Visual Basic Windows Form应用程序，构建在.net 3.5上（目前使用Visual Studio 2019 v16.11维护），它将数据存储在一个旧的，非常大（>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和
到目前为止，我还没有尝试过：
1.升级到Visual Studio '22（版本
- MariaDB连接字符串中的不同'OPTION'
如果你能帮忙的话
1条答案
按热度按时间ffvjumwh1#
如果我将“目标CPU”从“x86”更改为“AnyCPU”，则上述代码可以工作，或者至少不会显式出错。
好吧，你必须解决这个问题。vs 2019有两个版本，一个x32位版本和一个x64位版本。因此，您必须检查是否运行vs 2019的x64位版本。
你实际上必须解决这个问题。一个猜测的基础上的糖果工作与任何cpu？
这意味着你的MySQL/MariaDB驱动程序只有x64位，但是访问驱动程序（ACE数据引擎）是x32位的。
所以，不管怎样？你真的需要始终强制项目以“已知”位大小运行。
在vs 2022中，由于它现在是x64位产品（默认情况下），因此任何CPU都会导致x64位“进程中”运行应用程序。
在以前的vs版本中，任何CPU都会导致x32位运行应用程序。
这里的例外是vs 2019，因为它有两种口味。
不管任何CPU的“潜在”混乱问题？
我会建议，因为ms访问数据引擎是在这里参与？
您必须始终强制您的项目的位大小。选择x64或x86（x32位）并不重要，但您需要修复并强制执行此问题。
所以，要么你：
安装x64位Maria db驱动程序。或者ms访问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文件，并且在没有安装任何附加软件的情况下这样做。
然而，为了使您的软件能够工作，您必须将.net项目强制为x32位并以x32位运行。这也意味着您可以继续使用带有“JET”的连接字符串，而不是现在必须在这些连接字符串中使用“ACE”数据引擎。
所以，长话短说？
看起来你没有安装x32位版本的Maria/MySQL驱动程序。
安装该驱动程序，然后您就可以放心地将项目强制为x32（x86）。由于取决于VS的版本和您的计算机设置，使用任何CPU意味着从计算机到计算机，从VS的版本到更高版本，您不知道当按F5运行时，您会得到一个x32位“进程内”运行程序，还是一个x64位“进程内”运行程序。
实际上，我说的是，您希望将项目强制为给定的位大小，并且在开发和部署期间始终这样做。
最后但并非最不重要？
因为你可能需要或者在某个时候用ms-access打开数据库？（可能是压缩+修理，改变table设计等）？我会考虑在一个时间点切换到使用accDB文件格式，因为已经有一些版本的最新版本的office/Access在阅读和使用非常旧的“mdb”文件格式现在有困难。
但是，就目前而言，如果JET连接打开了mdb文件，那么就暂时坚持使用它。