VC6.0下用ODBC访问Access数据库：从环境配置到避坑指南

简介：基于VC6.0与MFC的ODBC访问Access数据库示例工程，内含一个学生信息管理系统，适合C++初学者或需要掌握数据库编程的开发者，用于学习通过ODBC统一接口连接Access并执行增删改查的完整流程。压缩包共278个文件，以C++头文件（.h）、源文件（.cpp）和编译中间文件（.obj）为主，另有Access数据库（.mdb）、可执行文件（.exe）及图标工具栏等资源，压缩后仅4.81MB，并附有完整的.dsw/.dsp工程文件，便于在VC6.0中直接打开编译。已有227人学习浏览。通过阅读和运行该示例，可掌握数据源（DSN）的配置，理解CDatabase、CRecordset等MFC类的封装用法，还能对照代码梳理从ODBC管理器建立数据源、程序自动连接数据库，到使用SQL语句实现记录集筛选与增删改查的完整操作链路；借助工程内的数据库文件和演示程序，可快速搭建自己的学生管理功能模块，是入门ODBC数据库编程的实用资料。

1. ODBC + Access + VC6.0：这套老组合到底解决了什么问题

ODBC 访问 Access 在 VC6.0 年代几乎是桌面数据库程序的标配方案，放到今天看依然没有完全退出历史舞台。很多企业内部还在跑的老系统，库存管理、小型 MIS、工单记录，底层就是这个组合：VC6.0 编译出来的 C++ 程序，通过 ODBC 接口连一个共享目录里的 Access 文件库。你如果接手这类维护需求，会发现文档大概率已经丢了，连 Access 数据文件本身也可能被拷来拷去，唯一能信的只有代码和 ODBC 那层薄薄的接口。这个标题里出现的.rar多半就是当年散落在项目里的数据库文件或源码备份——这类压缩包里的东西往往不是代码，而是这个系统的业务命脉。

我需要先说清楚一件事：这套组合适合谁。如果你在维护 2005 年之前写的桌面程序，或者在一家 IT 预算不高的公司里需要快速搭一个单机/小范围并发的小工具，那 Access + ODBC 依然是一个低成本、逻辑直观的选型。反过来，如果你的目标是新写一个面向互联网的高并发服务，那 Access 和 VC6.0 都不该出现在候选列表里。本文要解决的是前者：用 VC6.0 跑通 ODBC 访问 Access，搞清楚驱动、DSN、连接字符串、API 调用顺序和那些翻车点，然后照着能落地。

2. 环境准备：VC6.0 连 Access 前先把驱动和 DSN 查清楚

2.1 先确认系统里有没有能连 Access 的 ODBC 驱动

在写第一行代码之前，先弄清楚这台机器上的 ODBC 驱动列表里有没有 Access 对应的条目。很多老程序换一台新电脑就跑不起来，原因不是代码错了，而是驱动没装或者 DSN 没配。我在接到这类维护需求时，第一件事就是打开系统的 ODBC 数据源管理器，看一眼“驱动程序”页里有没有类似Access Driver (*.mdb)的条目。

# 在命令行里直接查已注册的 ODBC 驱动 reg query "HKLM\Software\ODBC\ODBCINST.INI\ODBC Drivers" /s

这条命令会把系统里已经安装的 ODBC 驱动名称列出来。你只需要关心存不存在 Access 驱动，而不是急着去改代码。正常装了 Office 或者安装了 Access 数据库引擎的机器，驱动列表里基本都会有对应条目。如果完全没有，后面任何连接代码都会直接报Data source name not found或者Driver not found。

参数说明：HKLM\Software\ODBC\ODBCINST.INI\ODBC Drivers是驱动清单的主键，每个子键就是一个驱动名。在 64 位系统上，如果你跑的是 32 位程序，还需要把命令里的路径换成HKLM\Software\WOW6432Node\ODBC\ODBCINST.INI\ODBC Drivers，这一点后面避坑章节会专门展开。

2.2 配置一个用户 DSN：用最简单的方式让程序和数据库匹配

驱动存在之后，第二步是配 DSN（数据源名称）。DSN 本质上就是一个注册表配置项，把“数据源的名字”和“Access 文件的路径、驱动名”绑定在一起。程序里只要写一个DSN=MyAccess，ODBC 就能自动找到对应的文件和驱动，不用在代码里写死绝对路径——这也是老项目里最常见的做法。

# 用注册表命令直接建一个 Access 的用户 DSN reg add "HKCU\Software\ODBC\ODBC.INI\MyAccessDSN" /v DBQ /t REG_SZ /d "D:\data\erp.mdb" /f reg add "HKCU\Software\ODBC\ODBC.INI\MyAccessDSN" /v Driver /t REG_SZ /d "C:\Windows\System32\odbcjt32.dll" /f reg add "HKCU\Software\ODBC\ODBC.INI\MyAccessDSN" /v DriverID /t REG_DWORD /d 25 /f reg add "HKCU\Software\ODBC\ODBC.INI\MyAccessDSN" /v UID /t REG_SZ /d "" /f

这样做完其实不太好，因为Driver键值写死了驱动 DLL 的路径，系统迁移时容易翻车。我一般在测试机上会用图形界面（ODBC 数据源管理器里的“用户 DSN”页）来完成这一步，命令行方式只用于批量部署。图形界面里选 Access 驱动，填数据源名和数据库路径，点几下就行，这比手写注册表可靠得多。

参数说明：DBQ是 Database Query 的简称，指向 Access 文件路径；Driver是驱动 DLL 的完整路径，在 64 位系统上用 32 位驱动时路径会变成C:\Windows\SysWOW64\odbcjt32.dll；UID一般留空，Access 的文件级密码不走这里。配完之后可以用reg query "HKCU\Software\ODBC\ODBC.INI\MyAccessDSN" /s验证是否真的有这几个键值。

2.3 代码里怎么连：DSN 与 DSN-Less 两种连接字符串

DSN 配好后，代码里的连接就简单了。VC6.0 环境下最常见的是用CDatabase打开一个 DSN，或者直接用 ODBC API 的SQLDriverConnect传连接字符串。两种写法我都见过大量历史代码，先说 DSN 方式：

// dsn_connect.cpp #include <afx.h> #include <odbcinst.h> CDatabase db; CString connStr = _T("DSN=MyAccessDSN;UID=;PWD=;"); try { db.OpenEx(connStr, CDatabase::noOdbcDialog); } catch (CDBException* e) { AfxMessageBox(e->m_strError); e->Delete(); }

逻辑说明：OpenEx的第一个参数是连接字符串，第二个参数noOdbcDialog表示不弹出 ODBC 登录框，连接失败时直接抛异常而不是弹窗。这样做的好处是程序可以把这个异常抓下来，写进自己的日志系统，而不是留一个黑匣子弹窗给操作员。

DSN-Less 写法把驱动名和文件路径写进连接字符串，不依赖注册表 DSN。驱动名要填系统驱动列表里显示的完整名字，连大括号一起写在里面。这种方式的好处是程序拷到哪都能跑，坏处是数据库路径被写死，环境一换就要改代码。我自己的习惯是：正式维护的代码用 DSN，因为部署时可以在每台机器上单独配路径；快速写的测试工具用 DSN-Less，因为不用去点 ODBC 管理器。

3. 访问方式怎么选：CRecordset、CDatabase 与直接 ODBC API

3.1 三层访问接口的分工

VC6.0 时代连 Access 至少有三条路。第一条是 MFC 的CRecordset，适合把一张表或查询结果直接映射到结构体字段，代码量最小；第二条是CDatabase直接执行 SQL，适合动态拼接的增删改语句；第三条是直接调 ODBC API，从环境句柄到语句句柄全部自己管理，适合对资源释放要求很严格或者要嵌进非 MFC 模块的场景。这三条路不是互斥的，一个稍微复杂点的老项目里往往同时出现。

有一个常见的误区是：觉得CRecordset一定能 SQL 注入安全，因为它是“封装好的”。实际上CRecordset在构造WHERE子句时如果你直接把用户输入拼进m_strFilter，一样是字符串拼接，一样有注入风险。这个封装给你的是便捷，不是安全。

3.2 CRecordset 的适用边界与它的小陷阱

// recordset_demo.cpp class CPersonSet : public CRecordset { public: CPersonSet(CDatabase* pDb) : CRecordset(pDb) {} CString m_strName; long m_nAge; virtual CString GetDefaultSQL() { return _T("person"); } virtual void DoFieldExchange(CFieldExchange* pFX) { pFX->SetFieldType(CFieldExchange::outputColumn); RFX_Text(pFX, _T("name"), m_strName); RFX_Long(pFX, _T("age"), m_nAge); } };

逻辑说明：GetDefaultSQL返回表名，DoFieldExchange负责把表的列和成员变量绑定。这里的字段名name和age必须和 Access 表里的列名完全一致，大小写不敏感但拼写不能错。你查一条记录以后，m_strName和m_nAge就被填充了。

CRecordset是这批封装类里最“顺手”的一个，但有一个隐蔽行为容易踩坑：它打开时会把整个结果集缓存到本地（取决于驱动支持的类型化行集），数据量一旦到了几万行，内存和首屏等待时间都会有明显体感。所以用它的时候一定要在Open的最后一个参数传CRecordset::forwardOnly，让它只前向游标读一次，不要默认的snapshot。这是我在一个导数据功能里亲眼看着查询时间从 40 秒降到 2 秒的改动。

3.3 直接 ODBC API 的时机：控制力换来的确定性

直接调 ODBC API 的代码更啰嗦，但它有一个无可替代的优势：每一句话柄的分配和释放都在你眼皮底下。对于那种要跑很长时间、还可能要反复连接断开的守护进程式程序，MFC 封装的内存管理黑匣子会让人很慌，不知道哪个对象内部还持着连接没放。而SQLAllocHandle/SQLFreeHandle的对称调用，一眼就能看出资源有没有配平。

另一个用 ODBC API 的常见场景是：程序不能依赖 MFC。比如某跨平台系统里，客户端逻辑用纯 C++ 写，只在 Windows 上有数据库模块，那直接#include <sql.h>会比强行拉一个CDatabase进来更干净。下表是我平时选型时的判断依据：

选型的核心不是“哪个更高级”，而是想清楚这个模块的生命周期谁来负责。MFC 封装替你管了，但替你管的同时也把错误恢复的时机藏起来了。我见过太多程序在Open失败之后继续往下跑，因为CDatabase内部的失败状态没有暴露给调用方，而直接写 API 就没有这种意外——返回值不是成功就是失败，不存在中间态。

4. 最小可跑工程：用 ODBC API 读写 Access 的完整代码

4.1 从环境句柄到查询结果的完整调用链

这一节给出一套能直接编译的骨架。VC6.0 的工程里，需要把odbc32.lib手动加进链接器输入，然后包含三个头文件：sql.h、sqlext.h、windows.h。头文件顺序不能乱，先 Windows 后 ODBC，否则会因为类型重定义报一堆看不懂的编译错误。

// odbc_access_demo.cpp #include <windows.h> #include <sql.h> #include <sqlext.h> #include <stdio.h> int main() { SQLHENV henv = SQL_NULL_HENV; SQLHDBC hdbc = SQL_NULL_HDBC; SQLHSTMT hstmt = SQL_NULL_HSTMT; SQLRETURN ret; // 1. 分配环境句柄，设置 ODBC 版本 ret = SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv); if (!SQL_SUCCEEDED(ret)) { printf("alloc env failed\n"); return 1; } ret = SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, 0); if (!SQL_SUCCEEDED(ret)) { printf("set env attr failed\n"); return 1; } // 2. 分配连接句柄并连接 ret = SQLAllocHandle(SQL_HANDLE_DBC, henv, &hdbc); if (!SQL_SUCCEEDED(ret)) { printf("alloc dbc failed\n"); return 1; } SQLCHAR connStr[] = "DSN=MyAccessDSN;UID=;PWD=;"; ret = SQLDriverConnect(hdbc, NULL, connStr, SQL_NTS, NULL, 0, NULL, SQL_DRIVER_NOPROMPT); if (!SQL_SUCCEEDED(ret)) { printf("connect failed\n"); return 1; } // 3. 分配语句句柄并执行查询 ret = SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt); if (!SQL_SUCCEEDED(ret)) { printf("alloc stmt failed\n"); return 1; } SQLCHAR sql[] = "SELECT id, name, age FROM person WHERE age > 20"; ret = SQLExecDirect(hstmt, sql, SQL_NTS); if (!SQL_SUCCEEDED(ret)) { printf("exec failed\n"); return 1; } // 4. 绑定列并逐行取数 SQLINTEGER id = 0, age = 0; SQLCHAR name[64] = {0}; SQLBindCol(hstmt, 1, SQL_C_LONG, &id, 0, NULL); SQLBindCol(hstmt, 2, SQL_C_CHAR, name, sizeof(name), NULL); SQLBindCol(hstmt, 3, SQL_C_LONG, &age, 0, NULL); while (SQLFetch(hstmt) == SQL_SUCCESS) { printf("id=%d name=%s age=%d\n", id, name, age); } // 5. 释放句柄，顺序与分配相反 SQLFreeHandle(SQL_HANDLE_STMT, hstmt); SQLDisconnect(hdbc); SQLFreeHandle(SQL_HANDLE_DBC, hdbc); SQLFreeHandle(SQL_HANDLE_ENV, henv); return 0; }

逻辑说明：第一步分配环境句柄，作用相当于打开 ODBC 驱动管理器的“会话”；第二步设置 ODBC 版本为 3.x，这一步如果不做，很多 Access 驱动会把 SQLSTATE 信息按老版本解释，排错时看到的错误码会差一个量级；第三步连接，我传了SQL_DRIVER_NOPROMPT，意思是连接参数不对时直接返回错误，绝不能让程序弹出 ODBC 登录框，否则无人值守环境里程序会一直挂在那里等你点确定；第四步查询，SQL_NTS表示字符串以空字符结尾，这是 C 字符串最常见的传法；第五步释放。

参数说明：SQLBindCol的第二个参数是列序号，从 1 开始，顺序对应SELECT里的列位置。第三个参数SQL_C_LONG和SQL_C_CHAR是 C 语言侧的类型，Access 驱动内部会做类型转换，把 ODBC 侧的 SQL_INTEGER / SQL_VARCHAR 转成你要的 C 类型。缓冲区大小sizeof(name)必须真实反映数组大小，如果驱动写入超过这个长度，取回来的数据会被截断且不会报错，这是我最想提醒的一个点。

4.2 SQL 参数化：把中文字面量从 SQL 字符串里抽出来

查询条件里带中文时，直接拼接 SQL 字符串有机会出现乱码和查不到数据的怪问题。常见做法是用SQLBindParameter把查询条件作为参数传进去，而不是拼在 SQL 文本里。这样做同时解决了两件事：编码问题交给驱动层处理，SQL 注入的隐患也一并消除。

// param_demo.cpp SQLCHAR sql[] = "SELECT id, name FROM person WHERE name = ?"; SQLBindParameter(hstmt, 1, SQL_PARAM_INPUT, SQL_C_CHAR, SQL_VARCHAR, 50, 0, (SQLPOINTER)searchName, strlen(searchName), NULL); ret = SQLExecDirect(hstmt, sql, SQL_NTS);

逻辑说明：?是参数占位符，SQLBindParameter把 C 变量searchName绑定到第一个占位符上面。执行时驱动会把变量的内容转成 Access 认可的编码后再拼进实际执行的 SQL 里，这一步就把“程序里的字符编码”和“SQL 文本的字符编码”解耦了。

参数说明：SQLBindParameter的第五个参数50是列的最大可能长度，Access 驱动会拿它做预检查；第六个参数是小数位数，整数字段填 0；第七个NULL是参数值的长度指针，对于以空字符结尾的字符串可以不传精确长度，驱动自己数。这里有一个细节：strlen(searchName)是按字节数算的，中文字符在 GBK 编码下是 2 字节，在不明确字符编码的程序里，这个长度直接决定驱动截不截断。

4.3 错误处理：只有返回值靠不住，还得看诊断记录

ODBC API 的SQL_SUCCEEDED只能告诉你这一调用是成功还是失败，没法告诉你为什么失败。真正有用的错误信息藏在驱动生成的诊断记录里，需要主动用SQLGetDiagRec把它捞出来。我在维护旧系统时，几乎每个关键调用后面都会跟一段捞错误的代码，不然程序只打印一个错误码，对排错没有任何帮助。

// diag_demo.cpp void dumpError(SQLSMALLINT handleType, SQLHANDLE handle, const char* tag) { SQLCHAR state[6] = {0}; SQLINTEGER nativeErr = 0; SQLCHAR msg[256] = {0}; SQLSMALLINT msgLen = 0; SQLGetDiagRec(handleType, handle, 1, state, &nativeErr, msg, sizeof(msg), &msgLen); printf("[%s] state=%s native=%d msg=%s\n", tag, state, nativeErr, msg); }

逻辑说明：SQLGetDiagRec的第一个参数是句柄类型，如果错误发生在连接阶段就传SQL_HANDLE_DBC，发生在语句阶段就传SQL_HANDLE_STMT。第二个参数是出错的句柄本身。第三个参数填 1 表示取第一条诊断记录。state是五字符的 SQLSTATE 码，nativeErr是驱动私有错误号，msg是人类可读的描述文本。有了这段代码，连接失败时你能直接看到08S01这样的连接异常码，而不是对着返回的-1发呆。

5. 避坑清单：驱动位宽、文件格式与中文乱码的五个坑

5.1 坑一：64 位系统上打开 ODBC 管理器，看不到 Access 驱动

现象：一台 64 位 Windows 上新装完 Office，打开 ODBC 数据源管理器，驱动列表里没有 Access 驱动；用代码连时直接报IM002：数据源未找到且没有指定默认驱动。

原因：系统上有两个 ODBC 管理器，一个管 64 位驱动，一个管 32 位驱动。默认从“管理工具”点开的是 64 位管理器；但 VC6.0 编译出来的程序是 32 位进程，它只能加载 32 位驱动。两边各看各的，你在 64 位管理器里配置了 DSN，32 位程序根本看不见。

解决：手动运行C:\Windows\SysWOW64\odbcad32.exe，这个才是 32 位的 ODBC 管理器。在这个里面配 DSN，32 位程序才能读到。我接到新机器环境时，第一步总是先确认这条路径存在，再去谈代码。

5.2 坑二：Access 新版本建的 .accdb 文件，老驱动打不开

现象：程序连接时提示“不是有效的文件名”或者“驱动无法打开数据库”，但文件明明存在，手动用 Access 能打开。

原因：老驱动只支持.mdb格式，Access 2007 之后新建的文件默认是.accdb格式，驱动不识别。

解决：确认 Access 文件的实际扩展名。如果是.accdb，两种办法：一是让业务方在 Access 里另存为2002-2003 格式的.mdb文件；二是换驱动。旧驱动对.mdb的兼容性最好，很多老系统的 Access 文件本身就是.mdb，这种情况下不用动。如果文件源确实是.accdb，就得在驱动列表里找支持*.accdb的新驱动，并保证代码编译成 32 位时这台机器有对应的 32 位版本驱动。

5.3 坑三：中文乱码不是 Access 的锅，是连接和代码页不一致

现象：INSERT 一条中文记录成功后，用 Access 打开看是乱码；或者反过来，Access 里显示正常的中文，程序查出来却是问号。

原因：程序里 SQL 语句的字符集和处理 ODBC 返回缓冲区的字符集不一致。VC6.0 默认工程字符集是 ANSI，Access 内部存储使用的是系统区域设置决定的编码。当系统区域设置是简体中文（GBK）时，ANSI 字符串一般是 GBK，可以显示正常；当系统区域设置被改成英文或其它地区时，变量里的字符已经错位，写入自然就乱。

解决：别在代码里假设字符集，把 SQL 文本从执行语句里拿出来，改用SQLBindParameter传参；取回中文字段后用 Unicode 查一次验证。具体做法是把程序字符集切到 Unicode 工程（VC6.0 里改项目设置），同时把SQL_C_CHAR对应改成SQL_C_WCHAR，让 ODBC 驱动按宽字符交换数据。这个改动会牵动很多代码，所以性价比最高的先做参数化，再考虑切 Unicode。

5.4 坑四：句柄泄漏比 SQL 错误更隐蔽

现象：程序长时间运行后，数据库操作越来越慢，最后报“不能连接”；重启程序后又恢复正常一段时间。

原因：SQLAllocHandle分配了语句句柄，但忘记在分支里释放。比如continue或return没有走释放代码，连接句柄被程序占住不放，Access 是老式的文件型数据库，没有大型数据库那样完善的连接池清理机制，句柄不释放就会一直占着文件锁。

解决：释放顺序必须和分配顺序相反。检测方法是打开任务管理器观察句柄数：闲着无事时句柄数缓慢爬升，基本就是泄漏。不要靠肉眼找，用一个简单的 RAII 包装最稳妥：

// raii_demo.cpp class StmtGuard { public: StmtGuard(SQLHDBC dbc) { SQLAllocHandle(SQL_HANDLE_STMT, dbc, &stmt); } ~StmtGuard() { if (stmt != SQL_NULL_HSTMT) SQLFreeHandle(SQL_HANDLE_STMT, stmt); } SQLHSTMT stmt = SQL_NULL_HSTMT; };

逻辑说明：这个类的析构函数保证不管函数是从正常路径结束还是从异常/return路径跳出，语句句柄都会被释放。VC6.0 的 C++ 编译器对栈上对象的析构调用是可靠的，这是一个投入极小、回报极大的习惯。

5.5 坑五：DSN 报错 “Data source name not found and no default driver specified”

现象：代码明明写了DSN=MyAccessDSN，却报IM002。去 ODBC 管理器里看，DSN 确实存在，名字也对。

原因：程序运行的账户和你配置 DSN 时用的账户不一致。用户 DSN 存在HKCU下，A 账户配的 DSN，B 账户运行程序就找不到；另外 32 位和 64 位两套注册表是隔离的，配置进错了位宽也会直接影响。

解决：排查时先确认程序进程是 32 位还是 64 位，再看对应位宽的 ODBC 管理器里用户 DSN和系统 DSN哪个有这条记录。系统 DSN 存在HKLM下，对所有账户可见，部署到服务器上时优先配系统 DSN。这个看起来像底层玄学的报错，九成以上就栽在位宽和账户两件事上。

6. 诊断技巧：用 SQLGetDiagRec 和跟踪日志定位连接问题

ODBC 层排查问题有一个金字塔思维：先怀疑驱动和配置，再怀疑代码里的调用顺序，最后才怀疑 SQL 语句本身。我在处理这类旧系统时，有个习惯是把SQLGetDiagRec的输出统一整理成一个标准日志函数，把所有关键调用的返回值、SQLSTATE、原生错误码和描述都打出来。但光靠这个还不够，因为有些问题发生在驱动内部，程序侧只看到“连接失败”。这时候就要用 ODBC 自带的跟踪功能。

在 32 位 ODBC 管理器里点“跟踪”页，启动跟踪后指定一个日志文件路径，比如D:\logs\odbc_trace.log，然后让程序重新跑一次故障路径。这个日志会把驱动收到的每一次调用、每一个参数的值、每一步返回的 SQLSTATE 全部记录成文本文件——相当于给这个黑匣子装了内窥镜。我排查过一次特别顽固的连接问题：程序里SQLDriverConnect总是返回SL009（没有可用的数据源），跟踪日志显示驱动实际尝试连接时通过了，但随后立即又断开，最终定位到是 Access 文件所在共享目录的权限问题。如果没有跟踪日志，我很难分清是驱动没装上还是网络路径不可达。

更有价值的是把两个诊断手段组合起来：程序里捞诊断记录用于日常运行监控，ODBC 跟踪日志用于现场排查异常时刻。前者让你在日志系统里看到用户反馈的报错码，后者让你看到驱动内部做了什么。我现在的习惯是，把所有数据库函数都包一层，函数入口打印传入参数，出口打印返回值，中间每次调用 ODBC API 失败时都调用一次dumpError。这样一旦线上出问题，先看程序日志判断是哪一步失败，再用跟踪日志还原现场，基本没有定位不出来的连接问题。

这个技巧的收益在维护老系统时特别明显。老代码里经常有大量“吞掉错误”的写法：调用完不看返回值直接往下走，等到用户反馈数据不对才发现。给这些老函数补一层诊断日志，比重新梳理业务逻辑要划算得多——业务逻辑可以等出问题再改，诊断能力必须现在就装上。我自己的教训是有一次接手一个模拟项目X的报表模块，报表数据偶尔少几行，花了大半天查 SQL 和业务代码，最后发现是有一个 ODBC API 调用在数据量大的时候悄悄失败了，而代码里根本没检查返回值。从那以后，凡是我过手的 ODBC 代码，每个调用后面必须有一条错误处理路径，要么打印、要么抛异常，绝不允许裸调用。这套习惯后来救过不止一次场，希望你也能在维护旧系统时用上，少走那些已经踩过的弯路。希望帮到你。

本文还有配套的精品资源，点击获取