简介这是一份面向 C/MFC 开发者的 ADO 数据库访问源码示例压缩包 Ado_Aok_demo.zip 定位为商业编程中的 ADO 交互参考适合需要快速掌握连接管理、SQL 执行、结果集遍历及事务控制的开发人员也可用于维护财务、库存或客户关系等典型数据驱动应用。包内共 26 个文件大小 41KB以 8 个 .h 头文件和 6 个 .cpp 源文件为核心另有 .dsw/.dsp 工程文件、.rc/.ico/.bmp 界面资源以及 msado15.tlh/.tli 类型库文件整体结构简要清晰便于逐项对照学习。已有 126 人学习下载。示例覆盖连接数据库、构建命令对象、使用 Recordset 读取数据、参数化查询防注入、异常错误处理、事务提交与回滚等常见商业场景同时包含插入、更新、删除及批量操作示例可帮助开发者理解在 MFC 工程中集成 ADO 的完整流程尤其适合希望从代码层面掌握 ADO API 用法、减少数据库层开发试错成本的初中级开发者。1. 从 Ado_Aok_demo 说起为什么 2025 年还要啃一份老 ADO 源码如果你打开这份Ado_Aok_demo.zip看到的是一堆.cpp、.h和msado15.tlh第一反应可能是「这都什么年代的货了」。但我要说的是在商业级 Windows 桌面程序里ADO 这套东西从来没死过。某财务系统、某跨平台系统、某图像处理Demo——凡是需要跟 SQL Server、Access 甚至 Oracle 打交道的 MFC 程序背后大概率还跑着 ADO 的Connection、Command、Recordset这套老伙计。这份源码的价值不在「新」而在它把 ADO 最常见的操作路径——连接、查询、参数绑定、结果集遍历、事务回滚——全部揉进了一个可以直接编译的 MFC 工程里。你不用去 MSDN 翻文档拼积木直接看AdoWrapper.h里那个封装类就知道生产环境的数据库访问层该怎么写。适合谁适合手上还维护着老 MFC 项目、想快速定位数据库问题的开发者也适合刚接手一个 ADO 遗留系统、需要一份能跑通的参考实现的从业者。2. 先看懂资源结构AdoTest 工程骨架与 AdoWrapper 封装思路2.1 从AdoTest.dsp到AdoTestDoc.cpp经典 MFC 文档视图结构这份资源的核心是一个名为AdoTest的 MFC 工程。.dsp和.dsw是 Visual C 6.0 时代的工程文件如果你用的是新版 Visual Studio首次打开时选择「不升级」直接查看源码即可或者用 VS 的转换向导把它转成.sln格式。工程采用标准的文档/视图架构AdoTestDoc负责数据管理AdoTestView负责显示。真正值得关注的是AdoWrapper.h——这个类把 ADO 的_ConnectionPtr、_CommandPtr、_RecordsetPtr封装成了更接近业务语义的接口。在数据库编程里原始 COM 接口用起来非常繁琐每一步都要检查HRESULT而封装类的意义就在于把Open、Execute、NextRecordset这些高频操作收敛到一个类里调用方只需要关心 SQL 和参数不需要关心 COM 生命周期。2.2 预编译头文件与msado15.tlh为什么这两个文件会被列出来StdAfx.h是 MFC 的预编译头msado15.tlh和msado15.tli是编译器从msado15.dll的类型库生成的 C 包装头文件。这两个文件很多人一眼扫过就忘了但它们决定了你能否成功编译。msado15.tlh里定义了_ConnectionPtr、_CommandPtr、_RecordsetPtr等智能指针类型这些指针封装了AddRef/Release让 COM 对象可以像普通指针一样使用。如果你在工程里找不到这两个文件需要在StdAfx.h中手动加入#import msado15.dll no_namespace rename(EOF, adoEOF) rename(BOF, adoBOF)这段代码的作用是导入 ADO 的类型库。no_namespace表示不使用命名空间限定直接暴露_ConnectionPtr等类型rename(EOF, adoEOF)是解决一个经典的宏冲突——EOF已经被stdio.h定义为 -1如果不重命名编译器会在Recordset的EOF属性处报错。rename(BOF, adoBOF)同理处理BOF与 MFC 内部定义的可能冲突。2.3 封装了什么AdoWrapper 的典型公共接口看AdoWrapper.h的内容常见的封装方法包括class CAdoWrapper { public: CAdoWrapper(); virtual ~CAdoWrapper(); BOOL Open(LPCTSTR lpstrConnection); BOOL ExecuteSQL(LPCTSTR lpstrSQL); _RecordsetPtr ExecuteQuery(LPCTSTR lpstrSQL); BOOL Close(); private: _ConnectionPtr m_pConnection; _CommandPtr m_pCommand; };Open负责创建_ConnectionPtr实例并调用Open方法建立连接ExecuteSQL用于执行 INSERT、UPDATE、DELETE 这类无返回集的命令ExecuteQuery返回_RecordsetPtr供上层遍历数据。注意_RecordsetPtr是智能指针不需要手动ReleaseRecordset但如果你在循环里反复创建Recordset建议在循环后调用m_pRecordset NULL主动释放避免连接池被拖垮。3. 连接管理实战连接字符串、打开超时与连接池陷阱3.1 连接字符串的构成从 ODBC 到 OLE DBADO 支持多种连接方式这份 Demo 中最常见的是 OLE DB 连接串。以 SQL Server 为例CString strConn; strConn.Format( _T(ProviderSQLOLEDB;Data Source%s;Initial Catalog%s;User ID%s;Password%s;), m_strServer, m_strDatabase, m_strUser, m_strPassword ); m_pConnection-Open((_bstr_t)strConn, , , -1);ProviderSQLOLEDB指定 OLE DB 提供程序为 SQL Server 专用驱动Data Source可以是服务器名或 IPInitial Catalog是数据库名。Open的最后一个参数-1表示使用默认超时实际生产环境你应该显式设置超时时间在Open前调用m_pConnection-ConnectionTimeout 15;设置 15 秒超时。经验值是重负载系统设为 5~10 秒内网环境 15 秒足够。如果设短了业务高峰时数据库短暂延迟会引发大量连接失败设长了数据库宕机时程序会长时间假死。3.2 连接管理的坑Close不等于释放看过很多新手的代码只调用m_pConnection-Close()就认为万事大吉实际上Close()只是关闭连接会话COM 对象本身的引用计数还在。正确做法if (m_pConnection ! NULL) { if (m_pConnection-State ! adStateClosed) m_pConnection-Close(); m_pConnection NULL; }State属性需要比较adStateClosed枚举值来判断当前连接是否已关闭。m_pConnection NULL这行的作用是让智能指针释放内部引用计数调用Release销毁 COM 对象。如果不做这一步每次重新连接时旧连接没有被完全释放连接池会被占满。3.3 连接池行为什么时候真正断开ADO 连接默认开启连接池。ConnectionTimeout只是建立连接时的等待时间连接关闭后对象会被回收到进程池物理 TCP 连接并不立即断开。这意味着如果你在代码里不断Open又Close数据库端看到的连接数不会剧烈波动但进程的句柄数会缓慢增长。要观察这个问题打开任务管理器看进程的句柄列如果每次操作后都有增量说明有连接对象泄漏。排查方法是逐层注释代码找到是哪条分支只创建了Connection对象但没有赋值NULL。4. Command 对象与参数化查询把 SQL 注入的风险关进笼子4.1 为什么不用Execute直接拼字符串AdoTestDoc.cpp里如果直接写m_pCommand-CommandText _bstr_t(SELECT * FROM Users WHERE UserName strUser );在演示环境没问题但生产环境就是灾难。SQL 注入的核心原理是用户输入被当作 SQL 代码解析。某公司 CRM 系统就出过这类事故——用户在前端输入框中填入 OR 11后台拼接 SQL 后变成WHERE UserName OR 11直接返回整张表。ADO 提供的Parameters集合正是为此设计的。4.2 参数化查询的标准写法_CommandPtr pCmd; pCmd.CreateInstance(__uuidof(Command)); pCmd-ActiveConnection m_pConnection; pCmd-CommandText _bstr_t(SELECT * FROM Users WHERE UserName? AND Age?); pCmd-Parameters-Append( pCmd-CreateParameter(UserName, adVarChar, adParamInput, 50, (_variant_t)strUserName) ); pCmd-Parameters-Append( pCmd-CreateParameter(Age, adInteger, adParamInput, 0, (_variant_t)(long)nAge) ); _RecordsetPtr pRs pCmd-Execute(NULL, NULL, adCmdText);CreateParameter的签名是CreateParameter(Name, Type, Direction, Size, Value)。adVarChar对应字符串类型adParamInput表示输入参数Size是字段长度上限Value是实际值。注意字符串参数必须指定Size这个值应该与数据库字段定义保持一致。如果数据库字段是VARCHAR(50)这里的Size就填 50填大了会走隐式转换填小了直接报DB_E_PARAMUNAVAILABLE。4.3 参数化时常见的翻车类型不匹配Age字段在 SQL Server 里是INT但代码却传了_variant_t包着short。ADO 类型映射时会把short解析成adSmallInt与目标字段的adInteger不匹配轻则数据截断重则直接报错。血泪经验是统一用long做整数型参数的中间类型再赋给_variant_t。浮点数用double日期用_variant_t包装COleDateTime不要用字符串传日期因为区域设置不同会让MM/dd/yyyy和yyyy-MM-dd互相打架。4.4 存储过程调用的边界Command 对象调用存储过程比拼接 SQL 更安全但参数方向必须处理对。SQL Server 存储过程的返回值RETURN 语句需要额外追加一个adParamReturnValue类型的参数并且要放在参数列表的最前面。很多人漏掉这一条导致Execute报错或返回值取不到。CommandType也要从adCmdText修改为adCmdStoredProcADO 才会按照存储过程的方式解析命令文本。5. 事务控制与错误处理这套源码里最接近「商业级」的部分5.1BeginTrans、CommitTrans和RollbackTrans商业应用里最常见的数据一致性场景是从 A 账户扣款、向 B 账户加款两步必须同时成功或同时回滚。ADO 的Connection对象直接支持事务操作if (FAILED(m_pConnection-BeginTrans())) { AfxMessageBox(_T(事务启动失败)); return FALSE; } try { ExecuteSQL(_T(UPDATE Accounts SET BalanceBalance-100 WHERE AccountID1)); ExecuteSQL(_T(UPDATE Accounts SET BalanceBalance100 WHERE AccountID2)); m_pConnection-CommitTrans(); } catch (...) { m_pConnection-RollbackTrans(); AfxMessageBox(_T(操作失败已回滚)); return FALSE; }BeginTrans成功后后续所有在同一个连接上执行的 SQL 都属于该事务。注意这里的ExecuteSQL函数内部必须复用同一个_ConnectionPtr对象不能每步重新Open一个连接。如果两个连接各自执行一条 SQL事务根本不在同一个会话里第一条成功、第二条失败时回滚也无法撤销第一条的修改。5.2 ADO 错误集合为什么catch(...)可能抓不到信息ADO 的 COM 接口错误会通过Error集合暴露而不是传统 C 异常。catch (...)只能捕获_com_error异常很多情况下错误码藏在m_pConnection-Errors里catch (_com_error e) { CString strError; strError.Format(_T(错误码: 0x%08X - %s), e.Error(), (LPCTSTR)e.Description()); // 遍历 Errors 集合获取更详细信息 ADOErrorsPtr pErrors m_pConnection-Errors; if (pErrors-Count 0) { for (long i 0; i pErrors-Count; i) { ADOErrorPtr pError pErrors-GetItem(i); strError _T(\n); strError (LPCTSTR)pError-Description; } } AfxMessageBox(strError); }_com_error::Error()返回的是HRESULT值比如0x80040E14对应 SQL Server 语法错误0x80040E4D对应权限不足。Description是本地化的错误描述文本中文系统下会返回中文。但有些时候Description是空的尤其是网络断开这类底层错误错误码才是真正的定位线索需要配合微软的ERRLOOK工具或在线数据库查看HRESULT对应的具体含义。5.3 事务的隔离级别默认级别够不够用ADO 的_ConnectionPtr默认隔离级别是adXactReadCommitted即读取已提交数据防止脏读。如果业务需要更高的隔离级别比如防止不可重复读可以设置m_pConnection-IsolationLevel adXactSerializable;adXactSerializable是最高隔离级别防止脏读、不可重复读和幻读。代价是并发性能显著下降因为数据库会对读取范围的键锁更长时间。库存管理系统通常用adXactReadCommitted已经足够财务对账系统可以考虑adXactSerializable。这里的取舍要看业务能接受多大的并发冲突概率没有标准答案。5.4 Recordset 的批处理模式离线修改后再回传AdoTestView.cpp里使用Recordset的方式大概率是直接读取但商业系统经常要支持离线修改。ADO 的客户端游标支持批处理更新pRs-CursorLocation adUseClient; pRs-Open(_bstr_t(sql), _variant_t((IDispatch*)m_pConnection.GetInterfacePtr()), adOpenKeyset, adLockBatchOptimistic, adCmdText); // 修改数据后 pRs-UpdateBatch(adAffectAll);adUseClient指定使用客户端游标adLockBatchOptimistic是批乐观锁。此时Recordset不再实时与服务器同步所有修改缓存在本地。UpdateBatch在adAffectAll模式下一次性把所有增删改发送到数据库。这个模式最阴险的地方在于pRs-Update()在批处理模式下会成功返回但真正的错误要等UpdateBatch才暴露。调试时看到Update正常就以为写入成功实际UpdateBatch里返回的错误才是真实状态。6. 避坑指南ADO 源码调试中 90% 的翻车现场6.1 现象Release 模式崩溃Debug 正常原因ADO 智能指针在 Debug 和 Release 下的内存布局不同_variant_t的析构顺序差异会引发访问冲突。最常见的位置是函数返回_variant_t或_RecordsetPtr时局部变量在 Release 模式下被提前释放。解决将返回值改为调用方传入的引用参数避免返回值构造临时对象。例如ExecuteQuery改为BOOL ExecuteQuery(CString strSQL, _RecordsetPtr pRs)在函数内部给pRs赋值。同时检查所有_variant_t变量是否在作用域结束时显式调用Clear()。6.2 现象Open方法每次都要等待 15 秒才失败原因ConnectionTimeout在首次连接失败后会缓存失败状态后续连接请求直接进入超时等待。这是 ADO 连接池的一个已知行为物理连接没有建立成功时池子不会缓存失败的句柄但等待逻辑会按最大超时时间阻塞。解决在Open前重置状态调用m_pConnection-Cancel()或m_pConnection NULL重新创建实例m_pConnection NULL; m_pConnection.CreateInstance(__uuidof(Connection)); m_pConnection-ConnectionTimeout 5;6.3 现象Recordset遍历时EOF永远为假导致死循环原因EOF宏被stdio.h的EOF-1覆盖。当你写了while (!rs-EOF)时rs-EOF被替换成rs--1实际上比较的是一块非法内存地址行为不可预测。解决import时重命名#import msado15.dll rename(EOF, adoEOF) rename(BOF, adoBOF)遍历条件写成while (pRs-adoEOF VARIANT_FALSE)。6.4 现象Execute返回值是NULL但 SQL 明明执行成功原因对于 INSERT、UPDATE 这类不返回数据集的 SQLExecute的返回集实际上是空的。部分驱动返回的_RecordsetPtr虽然是有效指针但RecordCount为 0还有一部分驱动直接返回NULL这是正常行为。解决不要对Execute的返回值做空指针判断来推断 SQL 是否成功改为检查错误集合和捕获的_com_error异常。对需要确认影响行数的场景使用Command对象执行后读取RecordsAffected_variant_t vAffected; _RecordsetPtr pRs pCmd-Execute(vAffected, NULL, adCmdText); long nCount (long)vAffected;6.5 现象字符乱码中文全部变成??原因连接字符串没有声明字符集或数据库字段与 ADO 参数的adVarChar类型不匹配。SQL Server 中文环境通常需要adVarWChar而不是adVarChar。解决连接字符串中追加Character SetUTF8ODBC或DataTypeCompatibility80OLE DB参数类型统一使用adVarWChar且Size填字节数中文字符按 2 字节计算。更稳妥的方案是把 SQL 语句中所有中文字面量改为N中文前缀强制按NCHAR类型处理。7. 高级用法单连接多结果集的 Pipeline 模式与族谱级调试技巧7.1 一次查询跑三类数据NextRecordset的实战价值有经验的开发者会注意到AdoTestView.cpp里可能只用了单条 SQL 查询但商业报表场景经常遇到「同一个页面要展示主表、明细表、统计值」的需求——传统做法是发三次请求而 ADO 的Command对象支持把多条 SQL 拼在一次Execute里执行然后用NextRecordset逐个取结果pCmd-CommandText _bstr_t( SELECT * FROM Orders WHERE StatusPending; SELECT * FROM OrderDetails WHERE OrderID IN (SELECT OrderID FROM Orders WHERE StatusPending); SELECT COUNT(*) FROM Orders WHERE StatusPending; ); _RecordsetPtr pRs pCmd-Execute(NULL, NULL, adCmdText); do { // 处理当前结果集 while (pRs-adoEOF VARIANT_FALSE) { // 取字段值... pRs-MoveNext(); } // 跳转下一个结果集 pRs pRs-NextRecordset(NULL); } while (pRs ! NULL);这个模式的瓶颈在于SQL Server默认只返回第一个结果集要启用多结果集需要在连接字符串里添加MultipleActiveResultSetsTrue。另外NextRecordset返回的_RecordsetPtr如果指向同一内存会出现调用MoveNext后之前的结果集内容丢失——所以每一层循环里要先把当前结果集的值拷贝到业务变量中再调用NextRecordset。经验不足的人在这里写的代码跑起来数据总是「差一行」多半就是忘了do-while里先取值再跳转的顺序。7.2 加一个 Unprepare 技巧让重复执行的 SQL 不再重新解析先看一个性能场景循环里执行一万次结构相同、参数不同的INSERT语句如果每次都用Execute直接跑数据库服务器每次都要做语法解析、生成执行计划。ADO 提供了Command对象的Prepared属性开启后数据库会缓存执行计划pCmd-CommandText _bstr_t(INSERT INTO Logs(LogTime, Message) VALUES(?, ?)); pCmd-Prepared TRUE; for (int i 0; i 10000; i) { pCmd-Parameters-Item[LogTime]-Value _variant_t(COleDateTime::GetCurrentTime()); pCmd-Parameters-Item[Message]-Value _variant_t(CString(_T(Batch Log))); pCmd-Execute(NULL, NULL, adCmdText); } pCmd-Prepared FALSE;Prepared TRUE会让 ADO 在第一次执行时向数据库发送sp_prepare预编译命令后续执行直接复用执行计划耗时从毫秒级降到亚毫秒级。代价是缓存结构占用数据库服务器内存并且如果 SQL 被频繁修改即参数少、文本变化多预编译可能反伤性能因为每次文本变化都会产生新的预编译计划。我一般会在循环体超过 100 次时才启用低于这个量直接裸跑 SQL。7.3 族谱级调试技巧SQL Server Profiler 是查 ADO 行为的最好镜子ADO 是黑匣子你看到的是_RecordsetPtr和_CommandPtr数据库服务端看到的是一串具体的 T-SQL 语句和参数。当出问题时很多人的第一反应是往 C 代码里塞AfxMessageBox打印每一步状态——调试了两小时也没定位到是参数传错还是 SQL 语法错误。正确做法是用 SQL Server Profiler 做族谱式排查打开Profiler新建跟踪事件选中SQL:StmtStarting、SQL:StmtCompleted、RPC:Starting、RPC:Completed在跟踪属性里勾选「显示所有列」特别是TextData、SPID、Duration运行你的程序执行数据库操作回到Profiler看TextData里实际执行的语句和参数值。当发现TextData里的参数与你传入的_variant_t值不一致说明CreateParameter的类型或大小参数指定错误ADO 帮你做了隐式转换当发现RPC:Completed的Duration高得离谱说明存储过程内部的性能瓶颈才是根因跟 ADO 无关。从那以后我每接到一个 ADO 相关的新需求都会先挂 10 分钟 Profiler 看基线数据再动手改代码——这个习惯帮我省掉了大量「看着像代码问题、其实是数据问题」的瞎猜时间。希望帮到你。本文还有配套的精品资源点击获取