有时候我发誓我们生活在数字石器时代。
事实证明 - 除非有人能指出我缺少的东西，ODBC 32位无法处理包含非默认语言环境字符的unicode路径名。
如果本地系统设置为相同的默认语言环境（例如当语言环境是日本时的汉字字符）， 处理具有非英语字符的路径名。
但无法完全使用我们的代码和ODBC 32位控制面板中的“Not a valid filename”来获取包含非默认语言环境字符的路径名。
使用64位ODBC控制面板正确加载同一个文件，它直接在路径名上加载了正常运行的MS Access 2013.
“C：\用户\史蒂夫\桌面\タシロ\ Cimex2.mdb”
在ODBC 32控制面板中，结果为：
ODBC Microsoft Access驱动程序登录失败
不是有效的文件名。
或者从我们的代码直接调用ODBC作为32位进程得到：
不是有效的文件名。
驱动程序的SQLSetConnectAttr失败
这是由于调用中的错误重新编码：
::SQLDriverConnect(hDBC, hWnd, pszConnectInput, SQL_NTS, szConnectOutput,
_countof(szConnectOutput), &nResult, wConnectOption));
更新 ：我被要求在此次通话时提供运行时状态：
使用以下方式创建连接：
L"DSN=Cimex Database|UserCommitSync=Yes|DBQ=C:\\Users\\steve\\Desktop\\タシロ\\Cimex2.mdb"
正在传递SQLDriverConnect：
L"DSN=Cimex Database;"
我已经验证了创建的ODBC连接确实有效（除了因为来自ODBC cpl的文件名无效而失败） - 但是如果我更改路径名以使用非Kanji路径，那么这一切都有效，因为它已经很久了。类似地，我已经在ODBC 32 cpl中直接手动创建了一个ODBC连接 - 以及在ODBC 64 cp中 - 并且对于相同的设置 - 只有64位版本工作 - 相同的.mdb＆amp;路径 - 但32位失败。并且以免你认为“它必须是.mdb” - 如果我将.mdb放在非Kanji路径中，它可以从我们的软件和ODBC 32 cpl中正常工作。
所以，在我看来，我找不到一个循环漏洞，32位ODBC Access驱动程序根本无法处理其中包含非默认语言环境字符的Unicode路径名。 ＆GT;：（
注意：我想也许SQL_NTS应该是SQL_NTSL（我不能在我的生活中找到一个！@＃$！@＃$定义这两个不同的参数），但是重新连接调用以SQL_NTSL结束没有帮助 - 结果相同
任何人都想确认或否认这是一个仍然隐藏在MS的32位Access ODBC实现中的主要因素（因为它是基于Jet引擎的 - 所以这可能适用于所有通过32位的数据库喷气发动机）？