简介：这份源码资源面向具备一定 C++ 基础、希望掌握 Windows 桌面端数据库开发的开发者，围绕 Visual C++ 通过 ODBC 接口访问 Access MDB 数据库这一典型场景展开。压缩包共 32 个文件，约 42KB，以 11 个 cpp 源文件与 12 个 h 头文件为主体，另含 ico 图标、rc 资源脚本、dsp/dsw 工程文件及一个 mdb 数据库文件，构成可直接编译运行的完整工程。内容以「通讯录」示例项目为主线，涵盖数据库连接建立、SQL 查询、记录集增删改操作、密码设置与修改、联系人信息维护等模块，并涉及 ODBC 错误处理与调试思路。读者可借此理解 CDatabase、CRecordset 等 MFC 类在实际项目中的组织方式，掌握连接字符串配置、异常捕获与基本性能优化要点。目前已有 382 人学习，适合作为 ODBC 数据库编程的入门练手与代码参考。
1. 用 Visual C++ 源码直连 ODBC 读写 Access MDB：一条被低估的桌面数据链路
接手一个老桌面工具时，数据层往往是最容易被忽略的部分。界面用 MFC 或纯 Win32 写得挺利索，可数据存哪、怎么查、怎么改，翻开源码一看——直接拿 ODBC API 怼 Access 的.mdb文件。很多人第一反应是「这都什么年代了还用 MDB」，但现实是：单机工具、离线环境、几十万行以内的结构化数据，Access MDB 配合 Visual C++ 的 ODBC 接口，部署成本几乎为零，不需要装数据库服务，一个文件拷走就能跑。这条链路的核心就是SQLDriverConnect/SQLExecDirect/SQLFetch这一套 C 接口，加上 Access 驱动对 SQL 方言的裁剪。它适合谁？适合维护存量桌面项目、做单机数据采集工具、或者需要在无服务端环境里落结构化数据的开发者。下面把我实际用过的连接、建表、增删改查、参数绑定和排错路径拆开讲，代码可以直接抄。
2. 连接串与驱动选型：为什么你的 SQLConnect 总是失败
2.1 Access 驱动在 32 位和 64 位下的真实差异
Visual C++ 项目连 Access MDB，第一个翻车点几乎都出在位数不匹配上。Access 的 ODBC 驱动分两套：32 位驱动（Microsoft Access Driver (*.mdb, *.accdb)）和 64 位驱动，它们分别注册在HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ODBC\ODBCINST.INI和HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI下。你的 VC++ 工程如果编译成 x64，却只装了 32 位 Office 带来的驱动，SQLDriverConnect会直接返回IM002（数据源名未找到且未指定默认驱动）。反过来，x86 工程配 64 位驱动同样连不上。
判断方法很直接：在「ODBC 数据源管理器」里看「驱动程序」页签，标题栏会写明是 32 位还是 64 位。或者用代码枚举：
// 枚举当前进程可见的 ODBC 驱动，确认 Access 驱动是否存在 #include <windows.h> #include <odbcinst.h> #include <tchar.h> void ListOdbcDrivers() { WORD maxName = 0, maxDesc = 0; SQLGetInstalledDrivers(nullptr, 0, &maxName, &maxDesc); // 先取缓冲区长度 if (maxName == 0) return; TCHAR* buf = new TCHAR[maxName]; if (SQLGetInstalledDrivers(buf, maxName, &maxName, &maxDesc)) { for (TCHAR* p = buf; *p; p += _tcslen(p) + 1) { _tprintf(_T("Driver: %s\n"), p); // 逐条打印驱动名 } } delete[] buf; }这段代码的关键是两次调用SQLGetInstalledDrivers：第一次传nullptr拿长度，第二次才真正取数据。参数maxName和maxDesc是输出参数，分别返回驱动名和描述的最大长度。如果你在输出里看不到任何含Access的驱动名，那问题不在代码，在环境。
提示：不要用
SQLConnect去连 MDB，它要求预先配置好 DSN。直连文件必须用SQLDriverConnect或SQLDriverConnectW，把文件路径写进连接串。
2.2 无 DSN 连接串的完整写法与参数含义
无 DSN（DSN-less）连接是桌面工具最常用的方式，因为不需要用户去 ODBC 管理器里配数据源。连接串的核心参数就几个：
// 无 DSN 连接 Access MDB 的完整示例 #include <sql.h> #include <sqlext.h> SQLHENV hEnv = SQL_NULL_HENV; SQLHDBC hDbc = SQL_NULL_HDBC; SQLHSTMT hStmt = SQL_NULL_HSTMT; bool ConnectMdb(const wchar_t* mdbPath) { SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &hEnv); SQLSetEnvAttr(hEnv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, 0); SQLAllocHandle(SQL_HANDLE_DBC, hEnv, &hDbc); // 连接串：驱动名 + 数据库绝对路径 + 只读/读写模式 std::wstring connStr = L"DRIVER={Microsoft Access Driver (*.mdb, *.accdb)};" L"DBQ=" + std::wstring(mdbPath) + L";" L"Uid=;Pwd=;"; // Access 无密码时留空 SQLWCHAR outStr[1024]; SQLSMALLINT outLen = 0; SQLRETURN ret = SQLDriverConnectW( hDbc, nullptr, (SQLWCHAR*)connStr.c_str(), SQL_NTS, outStr, 1024, &outLen, SQL_DRIVER_NOPROMPT); // 不弹驱动自带对话框 if (!SQL_SUCCEEDED(ret)) { // 这里应调用 GetDiagRec 取详细错误，见 2.3 return false; } SQLAllocHandle(SQL_HANDLE_STMT, hDbc, &hStmt); return true; }DBQ必须是绝对路径，相对路径在部分驱动版本下会被解析到系统目录，导致「文件找不到」。SQL_DRIVER_NOPROMPT很重要，否则驱动可能弹出一个要求用户选文件的对话框，在后台服务或自动化场景里会卡死。SQL_OV_ODBC3是必须设置的，不设的话默认按 ODBC 2.x 行为，某些函数返回值和字符串处理会有差异。
2.3 用 GetDiagRec 把错误码翻译成人话
ODBC 的返回值只有SQL_SUCCESS、SQL_SUCCESS_WITH_INFO、SQL_ERROR等几种，真正的原因藏在诊断记录里。封装一个错误打印函数，能省掉大量猜测时间：
// 打印 ODBC 诊断信息，定位连接/执行失败原因 void PrintOdbcError(SQLSMALLINT handleType, SQLHANDLE handle) { SQLWCHAR state[6] = {0}; SQLWCHAR msg[1024] = {0}; SQLINTEGER nativeErr = 0; SQLSMALLINT msgLen = 0; SQLSMALLINT recNum = 1; while (SQLGetDiagRecW(handleType, handle, recNum, state, &nativeErr, msg, 1024, &msgLen) != SQL_NO_DATA) { wprintf(L"[%s] Native=%d: %s\n", state, nativeErr, msg); recNum++; } }state是 SQLSTATE 五字符码，比如IM002是数据源未找到，28000是登录失败，42S02是表不存在。nativeErr是驱动自己的错误号，Access 驱动下常见的有-1907（密码无效）等。把这两个码记住，排查速度会快很多。
3. 建表、增删改查：把 SQL 语句塞进 C++ 的正确姿势
3.1 用 SQLExecDirect 执行 DDL 与 DML
Access 的 SQL 方言和标准 SQL 有出入，建表时字段类型要用 Access 认的写法。下面是一个完整的建表加插入流程：
// 建表 + 插入 + 查询的完整流程 bool CreateAndInsert() { // 建表：Access 支持 COUNTER 自增、TEXT、LONG、DATETIME 等类型 const wchar_t* createSql = L"CREATE TABLE DeviceLog (" L" Id COUNTER PRIMARY KEY," // 自增主键 L" DeviceName TEXT(64)," // 短文本，必须指定长度 L" Value DOUBLE," // 双精度 L" LogTime DATETIME" // 日期时间 L")"; SQLRETURN ret = SQLExecDirectW(hStmt, (SQLWCHAR*)createSql, SQL_NTS); if (!SQL_SUCCEEDED(ret)) { PrintOdbcError(SQL_HANDLE_STMT, hStmt); return false; } // 插入：用参数绑定避免拼接字符串 const wchar_t* insertSql = L"INSERT INTO DeviceLog (DeviceName, Value, LogTime) VALUES (?, ?, ?)"; SQLPrepareW(hStmt, (SQLWCHAR*)insertSql, SQL_NTS); wchar_t name[] = L"Sensor-A"; double val = 23.5; // 时间用字符串传入，Access 能自动转换 wchar_t timeStr[] = L"2025-01-15 10:30:00"; SQLBindParameter(hStmt, 1, SQL_PARAM_INPUT, SQL_C_WCHAR, SQL_WVARCHAR, 64, 0, name, 0, nullptr); SQLBindParameter(hStmt, 2, SQL_PARAM_INPUT, SQL_C_DOUBLE, SQL_DOUBLE, 0, 0, &val, 0, nullptr); SQLBindParameter(hStmt, 3, SQL_PARAM_INPUT, SQL_C_WCHAR, SQL_WVARCHAR, 19, 0, timeStr, 0, nullptr); ret = SQLExecute(hStmt); if (!SQL_SUCCEEDED(ret)) { PrintOdbcError(SQL_HANDLE_STMT, hStmt); return false; } return true; }SQLBindParameter的参数顺序是：语句句柄、参数序号（从 1 开始）、输入输出类型、C 类型、SQL 类型、列大小、小数位数、值指针、缓冲区长度、长度指示器指针。这里最容易错的是 C 类型和 SQL 类型的配对：字符串用SQL_C_WCHAR配SQL_WVARCHAR，双精度用SQL_C_DOUBLE配SQL_DOUBLE。配错了不一定报错，但数据可能被截断或变成乱码。
3.2 查询结果集：SQLFetch 与列绑定
查询比插入多一步：绑定结果列。有两种方式，一是SQLBindCol预先绑定，二是SQLGetData逐列取。前者适合列数固定的场景，后者适合动态列。
// 查询并遍历结果集 bool QueryAll() { const wchar_t* sql = L"SELECT Id, DeviceName, Value, LogTime FROM DeviceLog ORDER BY Id"; SQLRETURN ret = SQLExecDirectW(hStmt, (SQLWCHAR*)sql, SQL_NTS); if (!SQL_SUCCEEDED(ret)) { PrintOdbcError(SQL_HANDLE_STMT, hStmt); return false; } SQLINTEGER id = 0, idInd = 0; wchar_t name[128] = {0}; SQLINTEGER nameInd = 0; double val = 0; SQLINTEGER valInd = 0; wchar_t timeBuf[32] = {0}; SQLINTEGER timeInd = 0; SQLBindCol(hStmt, 1, SQL_C_LONG, &id, 0, &idInd); SQLBindCol(hStmt, 2, SQL_C_WCHAR, name, sizeof(name), &nameInd); SQLBindCol(hStmt, 3, SQL_C_DOUBLE, &val, 0, &valInd); SQLBindCol(hStmt, 4, SQL_C_WCHAR, timeBuf, sizeof(timeBuf), &timeInd); while (SQLFetch(hStmt) == SQL_SUCCESS) { // 检查指示器：SQL_NULL_DATA 表示该列为 NULL if (nameInd != SQL_NULL_DATA) { wprintf(L"Id=%d Name=%s Value=%.2f Time=%s\n", id, name, val, timeBuf); } } SQLFreeStmt(hStmt, SQL_CLOSE); // 关闭游标，保留语句句柄 return true; }指示器变量（idInd等）不能省。当某列为 NULL 时，SQLFetch返回SQL_SUCCESS，但指示器会被置为SQL_NULL_DATA，此时缓冲区内容未定义。不检查指示器直接读，就是玄学 bug 的来源。SQLFreeStmt用SQL_CLOSE而不是SQL_DROP，是为了复用语句句柄，避免频繁分配释放。
3.3 事务与批量插入的性能取舍
Access MDB 单条插入很慢，因为每次SQLExecute都可能触发一次磁盘写。批量插入时务必开事务：
// 事务包裹批量插入，性能提升明显 SQLSetConnectAttr(hDbc, SQL_ATTR_AUTOCOMMIT, (SQLPOINTER)SQL_AUTOCOMMIT_OFF, 0); for (int i = 0; i < 1000; i++) { // ... 绑定参数并 SQLExecute ... } SQLEndTran(SQL_HANDLE_DBC, hDbc, SQL_COMMIT); // 提交 SQLSetConnectAttr(hDbc, SQL_ATTR_AUTOCOMMIT, (SQLPOINTER)SQL_AUTOCOMMIT_ON, 0);关掉自动提交后，1000 条插入通常能从几十秒降到一两秒。但要注意：事务期间如果程序崩溃，数据不会落盘。所以批量操作要么全成功要么全回滚，中间不要做需要用户交互的事。
4. 避坑与排查：那些让 MDB 连接反复翻车的细节
4.1 现象：连接返回成功，但一执行 SQL 就报「无法锁定文件」
原因通常是 MDB 文件被其他进程以独占方式打开，或者当前进程没有该文件的写权限。Access 驱动在打开文件时会生成一个.ldb锁文件，如果目录只读，锁文件创建失败，后续操作全部失败。解决：确认文件所在目录有写权限，并检查是否有其他程序（比如 Access 本身）正打开该文件。
4.2 现象：中文写入后变成问号或乱码
原因有两个层面。一是连接串或 SQL 语句用了 ANSI 版本函数（SQLExecDirectA），而数据库的排序规则不支持中文。二是SQLBindParameter的列大小给得太小，中文字符在 UTF-16 下占两个字节，按字符数算容易截断。解决：统一用W后缀的宽字符函数，列大小按字符数给足，TEXT(64)就绑 64 而不是 32。
4.3 现象：SQLFetch返回SQL_ERROR，但错误信息为空
这种情况多半是结果集列绑定和 SELECT 列数不匹配。比如 SELECT 了 4 列，却只绑定了 3 列，驱动在取第 4 列时找不到绑定，报错但诊断信息可能不完整。解决：核对SQLBindCol的列序号与 SELECT 列表一一对应，或者改用SQLGetData按需取。
4.4 现象：程序在 64 位下编译，连接串正确却始终IM002
回到 2.1 的位数问题。64 位进程只能加载 64 位 ODBC 驱动。如果机器上只有 32 位驱动，要么把工程改成 x86 编译，要么安装 64 位驱动。没有第三条路。用ListOdbcDrivers在目标进程里跑一遍，比任何猜测都可靠。
4.5 现象：批量插入到一半程序无响应
Access MDB 在事务中会持有锁，如果同时有另一个连接在读同一张表，可能互相等待。解决：批量写入时避免并发读；或者把批量拆小，每 500 条提交一次，降低锁持有时间。另外，SQL_ATTR_AUTOCOMMIT关掉后忘记提交，也会导致后续连接看不到数据。
5. 进阶技巧：把 ODBC 封装成可复用的 C++ 类与验证方法
走到这里，裸调 ODBC API 的代码已经能跑通，但每个函数里都散落着SQLAllocHandle和错误检查，维护起来很痛苦。我一般会封一个轻量 RAII 类，把句柄生命周期和错误转换收进去。核心思路是：构造函数里分配环境和连接句柄，析构函数里按相反顺序释放；Execute方法接受宽字符串 SQL，内部调SQLExecDirectW，失败时抛一个带 SQLSTATE 的异常。
// 极简 RAII 封装示意：句柄自动释放，错误转异常 class MdbConnection { SQLHENV hEnv_ = SQL_NULL_HENV; SQLHDBC hDbc_ = SQL_NULL_HDBC; public: explicit MdbConnection(const std::wstring& mdbPath) { SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &hEnv_); SQLSetEnvAttr(hEnv_, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, 0); SQLAllocHandle(SQL_HANDLE_DBC, hEnv_, &hDbc_); std::wstring cs = L"DRIVER={Microsoft Access Driver (*.mdb, *.accdb)};DBQ=" + mdbPath + L";"; SQLWCHAR out[512]; SQLSMALLINT outLen = 0; if (!SQL_SUCCEEDED(SQLDriverConnectW(hDbc_, nullptr, (SQLWCHAR*)cs.c_str(), SQL_NTS, out, 512, &outLen, SQL_DRIVER_NOPROMPT))) { throw std::runtime_error("ODBC connect failed"); // 实际应带 SQLSTATE } } ~MdbConnection() { if (hDbc_ != SQL_NULL_HDBC) { SQLDisconnect(hDbc_); SQLFreeHandle(SQL_HANDLE_DBC, hDbc_); } if (hEnv_ != SQL_NULL_HENV) { SQLFreeHandle(SQL_HANDLE_ENV, hEnv_); } } SQLHDBC handle() const { return hDbc_; } };封装之后，业务代码里不再出现裸句柄，异常路径也统一了。但要注意：RAII 类不要拷贝，拷贝会导致双重释放，把拷贝构造和赋值运算符删掉。
验证方法上，我习惯写一个最小闭环测试：建一个临时 MDB 文件，建表、插 10 条、查出来、比对数量、删表、关连接。这个测试跑通，说明驱动、位数、连接串、SQL 方言、字符集全部对齐。任何一环有问题，它都会在具体步骤上暴露出来，比在业务代码里大海捞针强得多。
最后说个血泪教训：早期我图省事，把 MDB 文件路径用相对路径写死，本机测试一切正常，拷到别人机器上就报「文件找不到」。后来统一改成从可执行文件所在目录拼接绝对路径，再没翻过车。另外，Access 驱动对并发支持很弱，单机工具够用，一旦有多进程同时写，趁早换 SQLite 或服务端数据库。这个方向值不值得投入？如果你维护的是存量桌面项目、数据量在几十万行以内、部署环境不允许装数据库服务，那它依然是成本最低的落地路径。希望帮到你。
本文还有配套的精品资源，点击获取
