简介面向VC数据库开发初学者与需要巩固ADO基础的开发者这份实例资料聚焦ADO核心组件Command对象的使用帮助读者理解如何通过_CommandPtr智能指针在C项目中执行SQL语句、调用存储过程以及完成带参数的查询。资源包共11个文件压缩后约8KB以3个cpp源文件和3个h头文件为主体配合vcxproj、sln等Visual Studio工程配置构成可直接打开编译的TestAdo演示项目另附一份txt说明文件指向配套文章便于对照阅读。目前已有528人学习关注。项目代码围绕连接绑定、CommandText与CommandType设置、CreateParameter创建输入参数、Execute返回记录集或影响行数等环节展开并涉及事件处理与异常捕获的写法读者可据此跑通一遍完整流程再迁移到自己的数据访问模块中减少在参数类型与存储过程调用上的试错成本。1. 一个 VC 老项目里的 SQL 执行入口为什么我最后选了 _CommandPtr去年接手一个维护了七八年的 VC 客户端数据层全是_ConnectionPtr拼字符串执行 SQL改一个查询条件就要动一次格式化代码注入风险和空指针崩溃轮着来。重构时我把所有执行点收到一个口子上试过Recordset-Open、试过裸Connection-Execute最后落在_CommandPtr上——它是 ADO 三个核心对象里最适合承接「参数化 SQL 存储过程」的那一层。这个实例围绕 VC ADO 的 Command 对象展开讲清它怎么建、参数怎么绑、结果怎么取、错怎么排。适合手里有 VC/MFC 老代码、要接数据库、又不想引第三方库的人也适合刚学 ADO 只会拼 SQL 字符串、想弄明白_CommandPtr到底解决什么问题的开发者。2. 工程骨架与技术选型ADO 三个核心对象在 VC 里的落位ADO 在 VC 里不是一份源码而是一份 COM 类型库。工程要做的只有三件事把类型库导入进来生成包装类、把 COM apartment 初始化好、按对象模型把三个智能指针串起来。下面按「对象模型 → 工程配置 → 目录结构」三层拆。2.1 从 Connection 到 Recordset_CommandPtr 卡在链路中间ADO 的对象模型是一条链Connection一次会话→Command一条命令→Recordset结果集。_CommandPtr的位置很关键它既不是必需的一环也不是可随便绕过的。不带Command时写法是pConn-Execute(sql, vtRows, adCmdText)SQL 文本直接作为字符串传进去参数只能靠自己拼接。带Command时SQL 与参数分离参数通过Parameters集合单独绑定由驱动层做类型校验和转义。三条路径的取舍我一般这么判断使用场景推荐对象原因一次性简单查询、SQL 里无外部输入Connection-Execute代码最短无需额外对象开销需要带参数、反复执行的 SQL_CommandPtradCmdText参数与文本分离避免拼接与注入调用存储过程、带输出参数_CommandPtradCmdStoredProc只有 Command 能拿到输出参数与 RETURN 值大批量插入、多次复用同一语句_CommandPtr 事务语句只解析一次配合批次提交可控选_CommandPtr的真实理由不是「ADO 官方推荐」而是它能拿到RecordsAffected。在执行 UPDATE/DELETE 时Connection-Execute返回的 Recordset 是空的影响行数得从第一个参数里取而 Command 的 Execute 同样返回这个 out 参数但在参数化语句里你能确定这条行数是本次这条语句产生的不是别人拼接进来的。对象模型还有个常被忽略的点Command的ActiveConnection可以是Connection对象也可以是一个连接字符串。前者复用已有会话连接池友好后者每次执行会隐式新建连接。我一般用前者只在极少数「一次录入全表」的批处理脚本里才用后者省掉显式 Open 的代码。2.2 引入类型库msado15.dll 的 import 写法与常见编译配置VC 用#import指令把msado15.dll里的类型库翻译成.tlh/.tli两个头文件然后把_ConnectionPtr、_CommandPtr、_RecordsetPtr、_variant_t、_bstr_t这些_com_ptr_t智能指针给你。这份导入代码必须放在一个只编译一次的位置否则每个 cpp 都生成一份tlh链接期会出现重定义。// stdafx.h或预编译头中统一引入只在预编译单元里生效 #import C:\Program Files\Common Files\System\ado\msado15.dll \ no_namespace \ rename(EOF, EndOfFile) \ rename(BOF, BeginOfFile) \ rename(DeleteFile, AdoDeleteFile) \ rename(GetObject, AdoGetObject) // 参数说明 // no_namespace 不生成 ADODB 命名空间全局直接用 _CommandPtr // 若想隔离可换成 rename_namespace(ADODB)代码里写 ADODB::_CommandPtr // rename(EOF, ...) 类型库里的 EOF 属性和 stdio.h 的宏 EOF 同名不重命名必然编译报错 // rename(BOF, ...) 同上BOF 在部分 SDK 头里也有冲突 // DeleteFile/GetObject 与 Win32 API 同名一并改名避免链接歧义这段导入代码的第一个坑是路径。msado15.dll在 32 位系统上位于C:\Program Files\Common Files\System\ado\64 位系统上这个目录同样存在它是 32 位版的副本但如果你把工程编成 x64导入的还是同一份类型库文件运行期却能找到 64 位的实现这一点通常没问题。真正的风险是硬编码盘符——若工程要拷到别的机器编译建议写成相对形式或改成#import msado15.dll让编译器沿 PATH 与系统目录查找头区域。我自己的习惯是在stdafx.h里用#pragma comment(lib, ...)补 DLL 的导入库不需要#import已经生成msado15.tlh中的_com_ptr_t模板代码链接时依赖的是系统自带的msado15.dll导出表工程里不用额外加.lib。导入之后记得处理_com_ptr_t在异常下的行为。#import生成的包装类默认会_com_raise_error抛_com_error也就是异常路径。如果你维护的是老式 MFC 代码全部用返回值判错那就在导入后加一个空实现的错误处理器// 关闭 #import 生成的自动异常抛出改为手动检查 hr // 注意一旦替换掉默认处理器_com_ptr_t 的 CreateInstance 返回空指针而非抛异常 void __stdcall AdoErrorHandler(HRESULT, IErrorInfo*) {}不过我在实际项目里还是保留默认抛异常的行为外层用try/catch (_com_error)统一接。原因很实际ADO 的错误信息SQL 状态、原生错误码、Description全部挂在IErrorInfo上走异常路径才能拿到完整的ErrorMessage和Source手动判 hr 再调GetErrorInfo反而罗嗦。2.3 最小可跑工程的目录与文件清单一个能跑起来的最小工程我一般拆成四个文件职责边界清楚后面加功能不会全堆在对话框类里。AdoCommandDemo/ ├── AdoCommandDemo.sln ├── AdoCommandDemo/ │ ├── stdafx.h // #import 类型库 公共头 │ ├── stdafx.cpp // 预编译头占位保证 tlh/tli 只生成一次 │ ├── DbEnv.h / DbEnv.cpp // COM 初始化/反初始化 连接串常量 │ ├── DbCommand.h/.cpp // Command 的薄封装建对象、绑参、执行、取结果 │ └── main.cpp // 业务入口调用 DbCommand 跑三条示例 SQL └── sql/ └── init.sql // 建库建表脚本含一条示例存储过程这个结构里stdafx.cpp不是摆设。#import放在stdafx.h里编译器会在每个包含它的 cpp 里重新生成msado15.tlh/.tli但只要工程开了预编译头实际编译时只会生成一次。反过来如果项目没开预编译头又到处 include就会出现LNK2005重定义。要么开 PCH要么把#import挪进一个单独的.cpp在头文件里只声明需要的类型。COM 初始化放在DbEnv里工程主入口一开始就调用// DbEnv.cpp #include stdafx.h #include DbEnv.h bool DbEnv::Init() { // 单线程单元STA。MFC 对话框工程也可以用 AfxOleInit() 代替 HRESULT hr ::CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); // S_FALSE 表示本线程已初始化过同样算成功 return SUCCEEDED(hr); } void DbEnv::Uninit() { ::CoUninitialize(); }CoInitializeEx的 apartment 模型必须和你后续使用 ADO 的线程匹配。所有 ADO 对象都是单元线程模型一个Connection对象创建在哪个 STA 里就只能在这个 STA 里用跨线程传指针过去轻则返回RPC_E_WRONG_THREAD重则直接崩在QueryInterface里。这是我踩过的第一个血泪经验——后台导出线程里复用了主线程的_ConnectionPtr跑十分钟必崩最后改成每个工作线程自己 Open 一条连接才消停。3. 核心链路拆解CommandText、Parameters、Execute 三段式怎么写Command 的使用永远是三段给CommandText赋值、按顺序把参数 Append 进Parameters、调Execute拿结果。三段里的每一段都有坑下面按对象逐个落代码。3.1 连接对象Connection 打开、超时与连接串参数_CommandPtr自己不建连接它靠ActiveConnection绑一条已打开的Connection。连接串的写法直接决定后面 Command 能不能正常绑参。// DbCommand.cpp —— 建立并打开连接 _ConnectionPtr DbCommand::OpenConn(const char* szConn) { _ConnectionPtr pConn; // CreateInstance 走 CoCreateInstance失败会抛 _com_error pConn.CreateInstance(__uuidof(Connection)); // 连接超时单位是秒默认 30卡网时体验极差一般压到 5 pConn-ConnectionTimeout 5; // 命令超时同样以秒计0 表示无限等待千万别留 0一条慢 SQL 能把 UI 挂死 pConn-CommandTimeout 30; try { // Open 四个参数连接串、用户、密码、选项 // 连接串里已经带了 User ID/Password后两个传空即可 pConn-Open(_bstr_t(szConn), _bstr_t(L), _bstr_t(L), adConnectUnspecified); } catch (_com_error e) { // e.Description() 是驱动返回的中文描述比 HRESULT 有用得多 OutputDebugStringW(e.Description()); throw; } return pConn; }连接串里我一般显式写全这几个键缺一个就可能走默认值踩坑ProviderSQLOLEDB;Data Source127.0.0.1,1433;Initial CatalogDemoDb; User IDdemo_user;Password******;Connect Timeout5;Use Procedure for Prepare1;Data Source后面跟端口时用逗号不是冒号这点和别的驱动不一样写错了报的是「未找到或无法访问服务器」看起来像网络问题实际是连接串语法问题。Use Procedure for Prepare1是让驱动在第二次执行同一 Command 时把它转成临时存储过程参数化语句反复跑的场景下能省掉重复解析但只在语句结构稳定时生效属于可选优化。adConnectUnspecified和adConnectAsync的区别也要注意后者会立刻返回连接在后台建立此后再调Command-Execute可能拿到「对象关闭时不允许操作」。异步连接只适合做那种「先连上再显示进度条」的场景业务代码里一律用同步。3.2 无参命令CommandText 加 Execute 返回记录集的完整代码最简单的用法是不带参数把 Command 当成一个「可以复用的 SQL 容器」。这类代码在示例里到处都是但完整带错误处理的并不多。// 无参查询返回结果集 _RecordsetPtr DbCommand::QueryNoParam(_ConnectionPtr pConn, const wchar_t* wszSql) { _CommandPtr pCmd; pCmd.CreateInstance(__uuidof(Command)); pCmd-ActiveConnection pConn; // 绑定已有会话复用连接池 pCmd-CommandText _bstr_t(wszSql); pCmd-CommandType adCmdText; // 明确告诉驱动这是 SQL 文本不是表名或存储过程 pCmd-Prepared VARIANT_TRUE; // 请求驱动预编译参数化语句才有意义 _variant_t vtAffected; // 出参受影响行数查询时无意义 _RecordsetPtr pRs pCmd-Execute(vtAffected, NULL, adCmdText); if (pRs NULL) // 无结果集时返回 NULL不能直接调 Close return NULL; return pRs; }这里有个容易忽略的细节Execute的第三个参数Options和CommandType是重复的。两者同时给时以谁为准实测是Execute的 Options 优先——如果你把CommandType设成adCmdStoredProc却在Execute里传adCmdText驱动会按文本去解析存储过程名报「找不到对象」。所以要么统一在CommandType上设、Execute传adCmdUnspecified要么反过来。我的习惯是两个都写同一个值虽然冗余但一眼能看出意图。返回的_RecordsetPtr默认是只读、仅向前游标adOpenForwardOnly/adLockReadOnly。这在只遍历一次的场景下最快但如果要取RecordCount它会返回 -1——因为仅向前游标不支持计数。需要行数时不要改游标类型多一次全表扫描不划算改成在 SQL 里加COUNT(*)或者遍历计数。3.3 带参命令CreateParameter 与 Parameters-Append 的顺序约束参数化是 Command 的核心价值。ADO 的?占位符按位置绑定没有命名参数的概念Oracle 除外这是最容易翻车的地方。// 带参查询按 id 与姓名前缀过滤 _RecordsetPtr DbCommand::QueryByIdName(_ConnectionPtr pConn, long nId, const wchar_t* wszName) { _CommandPtr pCmd; pCmd.CreateInstance(__uuidof(Command)); pCmd-ActiveConnection pConn; // 占位符用 ?顺序必须与下面 Append 的顺序严格一致 pCmd-CommandText _bstr_t(LSELECT id, name, amount FROM t_order WHERE id ? AND name LIKE ?); pCmd-CommandType adCmdText; pCmd-Prepared VARIANT_TRUE; // 参数 1整型输入长度对定长类型无意义传 sizeof 只为语义清晰 pCmd-Parameters-Append( pCmd-CreateParameter(_bstr_t(Lid), adInteger, adParamInput, sizeof(long), _variant_t(nId))); // 参数 2变长宽字符输入长度是“字符数”不是字节数 // 传 0 表示让驱动按实际值推断显式传长度时超过会被截断且不报错 _bstr_t bsName wszName; pCmd-Parameters-Append( pCmd-CreateParameter(_bstr_t(Lname), adVarWChar, adParamInput, bsName.length(), _variant_t(bsName))); _variant_t vtAffected; return pCmd-Execute(vtAffected, NULL, adCmdText); }参数顺序这件事必须咬死。ADO 内部对?的解析是「第几个问号配第几个参数」CreateParameter的第一个名字参数id、name对 SQL Server 来说只是备注驱动不会拿名字去匹配。所以代码里Append的顺序和 SQL 里?的书写顺序不一致就会出现「id 拿字符串去比、name 拿数字去比对」的错位而且不报错只是查出来的行数不对。这类 bug 最难查因为 SQL 本身看起来完全正常。另一个坑是Parameters-Refresh()。有些教程会教你「先 Execute 一次让驱动自动解析参数」或者执行前调Refresh。别这么干。Refresh会清空你已经 Append 的参数重新从服务器拿一遍参数列表对于adCmdText拿回来的是一个「未命名、类型未知」的参数集合你还得再按索引去补值。参数化语句的参数一律自己 Append不要混用 Refresh。只有在调用存储过程、且不想手工写参数列表时才用 Refresh且必须在设好CommandText和CommandType之后、Execute之前只调一次。长度参数再强调一遍adVarWChar的长度是字符数。写sizeof(wchar_t) * len会让驱动认为字段长度翻倍某些驱动版本下直接报「参数长度无效」写得太短则会静默截断插入进去的字符串少几个字用户反馈「保存后名字少一半」查半小时才发现是这里。3.4 存储过程调用adCmdStoredProc、输出参数与返回值的取值方式存储过程是 Command 相对 Connection 的唯一优势场景因为只有 Command 能持有输出参数。// 调用存储过程两个输入、一个输出、一个 RETURN 值 void DbCommand::CallProc(_ConnectionPtr pConn, long nOrderId, long nDelta) { _CommandPtr pCmd; pCmd.CreateInstance(__uuidof(Command)); pCmd-ActiveConnection pConn; pCmd-CommandType adCmdStoredProc; pCmd-CommandText _bstr_t(Lsp_UpdateOrderAmount); // 只写过程名不带 exec、不带库名 // 顺序按存储过程定义输入1、输入2、输出1、RETURN pCmd-Parameters-Append( pCmd-CreateParameter(_bstr_t(Lorder_id), adInteger, adParamInput, 0, _variant_t(nOrderId))); pCmd-Parameters-Append( pCmd-CreateParameter(_bstr_t(Ldelta), adInteger, adParamInput, 0, _variant_t(nDelta))); // 输出参数长度给 0Execute 之后由服务器回填类型与值 pCmd-Parameters-Append( pCmd-CreateParameter(_bstr_t(Lnew_amount), adInteger, adParamOutput, 0)); _variant_t vtAffected; pCmd-Execute(vtAffected, NULL, adCmdStoredProc); // 取值输出参数按索引从 1 开始RETURN 值固定叫 RETURN_VALUE long nNewAmount pCmd-Parameters-GetItem(_variant_t((long)3))-Value.lVal; long nRet pCmd-Parameters-GetItem(_bstr_t(LRETURN_VALUE))-Value.lVal; // nRet 为 0 表示过程内未显式 RETURN非 0 才是业务返回码 }这里最容易错的是参数顺序里RETURN_VALUE的位置。SQL Server 的过程返回值是隐式的第一个参数但 ADO 在Parameters集合里通常把它放在最后索引等于参数个数。稳妥写法是按名字取GetItem(_bstr_t(LRETURN_VALUE))别数索引。按索引取的时候一旦有人在过程里加了参数你的代码就静默读错位置。CommandText只写过程名。写成exec sp_xxx、带上dbo.前缀或者末尾加;1在adCmdStoredProc模式下都会被当成过程名的一部分报「找不到存储过程」。这一点和某些驱动不一样从别的数据库转过来的人特别容易在这里翻车。另外adParamOutput和adParamInputOutput的区别要分清纯输出参数不需要给初值给adParamOutput既要传进又要拿回的用adParamInputOutput且必须给初值否则过程里读到的是 NULL。adParamReturnValue这个类型一般不用手动 AppendADO 在调用存储过程时会为你补一个。3.5 增删改与事务AffectedRecords 取值和 BeginTrans 三件套INSERT/UPDATE/DELETE 走的是同一条 Command 链路区别只在怎么拿执行结果。// 增删改返回实际影响的行数 long DbCommand::ExecNonQuery(_ConnectionPtr pConn, const wchar_t* wszSql, long nId, const wchar_t* wszName) { _CommandPtr pCmd; pCmd.CreateInstance(__uuidof(Command)); pCmd-ActiveConnection pConn; pCmd-CommandText _bstr_t(wszSql); pCmd-CommandType adCmdText; pCmd-Prepared VARIANT_TRUE; pCmd-Parameters-Append( pCmd-CreateParameter(_bstr_t(Lname), adVarWChar, adParamInput, (long)wcslen(wszName), _variant_t(wszName))); pCmd-Parameters-Append( pCmd-CreateParameter(_bstr_t(Lid), adInteger, adParamInput, 0, _variant_t(nId))); _variant_t vtAffected; _RecordsetPtr pRs pCmd-Execute(vtAffected, NULL, adCmdText); // 非查询语句返回的 Recordset 是 NULL显式判一下再释放 if (pRs ! NULL) pRs-Close(); // RecordsAffected 的 vt 可能是 VT_I4 也可能是 VT_NULL语句无返回统一转一次再取 long nAffected 0; if (vtAffected.vt VT_I4) nAffected vtAffected.lVal; else if (vtAffected.vt VT_NULL || vtAffected.vt VT_EMPTY) nAffected -1; return nAffected; }RecordsAffected的坑在于返回值不一定是整数。驱动在「SET NOCOUNT ON」的批处理下会给你VT_NULL直接取vtAffected.lVal不会崩但拿到的是垃圾值。必须先看vt。这个细节我在一个统计脚本里吃过亏更新 200 行日志记成 0 行排查了一下午。多条语句要么全成功要么全回滚的场景用 Connection 的事务方法包住// 事务三件套BeginTrans / CommitTrans / RollbackTrans void DbCommand::Transfer(_ConnectionPtr pConn, long nFrom, long nTo, double dAmount) { // BeginTrans 返回嵌套层数1 表示最外层 long nLevel pConn-BeginTrans(); try { ExecNonQuery(pConn, LUPDATE t_account SET balance balance - ? WHERE id ?, nFrom, L); ExecNonQuery(pConn, LUPDATE t_account SET balance balance ? WHERE id ?, nTo, L); pConn-CommitTrans(); // 两层嵌套时只有最外层 Commit 才真正提交 } catch (_com_error e) { pConn-RollbackTrans(); // 回滚必须写在 catch 里不能只靠析构 OutputDebugStringW(e.Description()); throw; } }注意RollbackTrans和CommitTrans都是 Connection 的方法不是 Command 的。Command 本身没有事务边界它只是在一个连接会话里干活。所以事务粒度只能是「一条连接」两条连接之间做不了原子操作——这也是为什么分库分表场景下 ADO 的这套原生事务不够用。还有一点事务里的 Command 如果超时CommandTimeout到点连接状态会变成「不可用」此时再调RollbackTrans可能报「连接繁忙」。超时值要设得比事务里的最长语句再宽裕一些我一般把事务内的CommandTimeout临时抬到 60 秒出作用域再还原。4. 数据往返细节字段取值、_variant_t 类型转换与中文编码Command 只负责把语句送出去、把结果集拿回来真正写业务代码时耗在取值上的时间远多于执行。这一章讲字段怎么读、类型怎么转、中文怎么不丢。4.1 Fields-GetItem 的三种索引与 NULL 判定_RecordsetPtr取字段有三种写法性能和可读性各有取舍。// 遍历结果集并取值 void DbCommand::PrintOrders(_RecordsetPtr pRs) { while (!pRs-EndOfFile) // 注意rename 之后是 EndOfFile不是 EOF { // 方式一按序号0 基最快适合列顺序固定且自己写的 SQL _variant_t vId pRs-Fields-GetItem(_variant_t((long)0))-Value; // 方式二按字段名可读性最好适合列多、多人维护的查询 _variant_t vName pRs-Fields-GetItem(_bstr_t(Lname))-Value; // 方式三先拿 Field 对象再用下标需要判断字段是否存在时用这个 if (pRs-Fields-GetItem(_bstr_t(Lamount)) ! NULL) { _variant_t vAmount pRs-Fields-GetItem(_bstr_t(Lamount))-Value; } // NULL 判定必须写在取值之前vt 是 VT_NULL 时字段里没有值 if (vName.vt ! VT_NULL vName.vt ! VT_EMPTY) { CString strName (LPCTSTR)_bstr_t(vName); } pRs-MoveNext(); } }GetItem传long时必须包_variant_t((long)0)。直接写GetItem(0)会因为_variant_t的构造重载把 0 解释成VT_I2或指针空值编译可能过运行时拿到的是第 0 个字段或者直接抛「参数类型不正确」。这种隐式转换错误编译器不提示属于典型的玄学 bug。按名字取字段比按序号慢多少实测在 20 列、10 万行的遍历里差大概 5%8%。真正贵的是Value的VARIANT拷贝不是名字查找。所以除非是超大批量的导出我一般按名字取可维护性优先。EndOfFile的判断也有讲究。空结果集情况下EndOfFile一开始就是TRUE但如果游标被移到末尾之后又调MoveNext不同驱动行为不一致有的会抛异常。稳妥写法是while (pRs ! NULL !pRs-EndOfFile)并且MoveNext之后不再做别的判断。4.2 _variant_t / _bstr_t 的生命周期与类型强转_variant_t是VARIANT的 RAII 包装构造时 Init、析构时 Clear。这意味着它不能随便拷来拷去——每次拷贝都是一次VariantCopy深拷贝字符串。循环里写_variant_t v pRs-Fields-GetItem(...)-Value;每轮都要拷一次10 万行就是 10 万次堆分配能明显看到 CPU 打满但磁盘无 IO 的怪象。要转成基本类型别直接取.lVal尤其是adNumeric/adDecimal这类字段VARIANT的 vt 可能不是VT_I4而是VT_DECIMAL或VT_BSTR。统一走ChangeType更安全// 安全取值先 ChangeType 再取避免 vt 不匹配拿到垃圾值 long DbCommand::GetLong(_variant_t v) { if (v.vt VT_NULL || v.vt VT_EMPTY) return 0; if (v.vt VT_I4) return v.lVal; // 已经是整数直接取省一次转换 _variant_t vTmp v; if (FAILED(vTmp.ChangeType(VT_I4))) // 转换失败返回错误码不抛异常 return 0; return vTmp.lVal; } CString DbCommand::GetStr(_variant_t v) { if (v.vt VT_NULL || v.vt VT_EMPTY) return CString(); _bstr_t bs v; // _variant_t 到 _bstr_t 有隐式转换 return CString((LPCTSTR)bs); }_bstr_t的坑在长度上_bstr_t内部维护的是带长度前缀的 BSTR可以包含\0而(LPCTSTR)强转到CString时会按\0截断。这不是常见场景但如果字段存的是二进制转出来的字符串就会出现「取出来少一半」的现象看着像数据库丢了数据。最后一个隐式转换雷区_com_ptr_t的operator-在指针为空时直接返回空随后访问成员会崩。CreateInstance之后一定确认非空尤其是把它当成员变量缓存、启动时创建失败被吞掉异常的情况。4.3 中文与宽字符连接串、N 前缀和 CString 转换中文问题的根子在两处参数值怎么传、SQL 文本里的字面量怎么传。第一处是工程字符集。VC 工程如果设成「多字节字符集」CString是CStringA传给_bstr_t时走的是 ANSI→UTF-16 的转换用的是系统代码页。代码页不对比如数据库里是 UTF-8 存过来的中文就变问号。要么工程统一设成「Unicode 字符集」要么在转换时显式指定代码页// 从 UTF-8 字节流转成宽字符避免依赖系统代码页 CStringW DbCommand::Utf8ToW(const char* szUtf8) { int nLen ::MultiByteToWideChar(CP_UTF8, 0, szUtf8, -1, NULL, 0); CStringW strRet; ::MultiByteToWideChar(CP_UTF8, 0, szUtf8, -1, strRet.GetBuffer(nLen), nLen); strRet.ReleaseBuffer(); return strRet; }第二处是 SQL 里的中文字面量。参数化语句不存在这个问题值走参数通道不拼进 SQL但如果你在CommandText里写了WHERE name LIKE %张%就必须在字符串前加NN%张%。不加N的话SQL Server 会把它当 varchar 解析用当前库的排序规则做隐式转换跨排序规则的库之间直接变乱码。这个坑在做过一次库迁移之后我彻底记住了。第三处是参数类型。中文必须用adVarWChar不要用adVarChar。后者会走 ANSI 转换服务端代码页不匹配就丢字。对应的用adVarWChar时长度参数是字符数wcslen就行用adVarChar时一个中文字在 GBK 下占 2 字节在 UTF-8 下占 3 字节写strlen会因为字节数不够被截断。还有个隐蔽的LIKE查询里的通配符。参数化时写LIKE ?参数值本身要带%即_bstr_t(L%张%)。如果写成LIKE %?%问号会被当成普通字符永远查不到。这个和 3.3 节的顺序错位一样属于「语法都对、结果不对」的类型。5. 避坑与排查Command 对象调试时最常见的五类翻车现场ADO 的错误信息大多被_com_error包了一层直接看hr很难定位。下面五条是我这两年修过的、能在十分钟内定位的典型问题每条按现象、原因、解决写。5.1 现象Execute 报「对象关闭时不允许操作」代码里明明 Open 过原因基本是两件事之一。一是ActiveConnection赋的是连接字符串而不是已打开的Connection对象Execute时 ADO 内部临时建连接完了马上关此时再访问 Recordset 就提示关闭。二是Connection对象在另一个线程打开的跨 apartment 使用。解决把pCmd-ActiveConnection pConn;改成pCmd-ActiveConnection _variant_t((IDispatch*)pConn);确保按 IDispatch 传指针而不是走了连接串的转换路径。跨线程的改法是每个线程各自CoInitializeEx 各自 Open绝不共享_ConnectionPtr。另外检查Connection-Stateif (pConn-State adStateOpen)才往下走否则先 Open。这条检查我后来直接封进了OpenConn省得每次怀疑。5.2 现象编译报error C2059: 语法错误:“常量”指向EOF那一行原因msado15.dll类型库里有一个名为EOF的属性和stdio.h里的宏EOF值为 -1撞了。预处理阶段宏展开把EOF换成-1语法就崩了。解决#import时加rename(EOF, EndOfFile)。如果已经有很多代码在用pRs-EOF两种过渡方式一是在导入后手动#undef EOF再补一个#define EOF EndOfFile能编译过但很脏后续维护的人会找不到定义二是全量替换成EndOfFilerename是正解。BOF同理一并 rename不然腾出手来还会再撞一次。5.3 现象存储过程调用返回「参数 xxx 未提供值」或输出参数读到 0原因CreateParameter的名字和存储过程里的参数名不一致而这个不一致在adCmdStoredProc下是致命的。普通 SQL 的?占位符不看名字存储过程看。另外append 了adParamOutput但没给adParamInputOutput的初值过程里读到 NULL做加法后仍是 NULL最后回填回来的就是 0。解决参数名严格对齐过程定义包括前缀输出参数确认是纯输出还是输入输出输入输出必须给初值。排查时打开服务端语句审计看 ADO 实际发过去的过程调用文本参数个数和类型一眼就能对出来。不要靠猜也不要靠Parameters-Refresh那个会把参数集合顺序重排。5.4 现象大批量插入时内存持续上涨最后抛_com_error 0x8007000E内存不足原因循环里每轮都新建_CommandPtr且没有释放或者把_variant_t塞进 STL 容器后一直没清。_com_ptr_t是引用计数但_variant_t持有BSTR时也占堆内存。解决Command 对象提到循环外创建参数值用Parameters-GetItem(n)-Value _variant_t(...)就地赋值比每轮重新Append快一个数量级也不会让参数集合越堆越大。循环内的中间变量用花括号限定作用域让析构及时发生。再配一个SQLBulkOperations或批量批处理每 500 条 Execute 一次10 万行插入从几分钟降到几秒。批量提交记得包事务否则每次 Execute 都刷一次日志磁盘 IO 会顶满。5.5 现象查询条件里明明有数据SQL 在客户端执行能查到代码里查不到原因参数类型与字段类型不匹配走了隐式转换。典型是字段nvarchar参数传adVarChar跨代码页比较时索引失效甚至比较结果不等或者字段是datetime参数传的是字符串格式随区域设置变化。解决按字段类型精确指定参数类型nvarchar配adVarWChardatetime配adDBTimeStamp且值用_variant_t的VT_DATEdecimal配adNumeric并显式给NumericScale。查不到的时候先不要怀疑 SQL把CommandText和参数值逐个打日志再到数据库端用同样的值手工执行一次——差异立刻就能看出来。这一步听着笨但它省下的时间比任何调试技巧都多。6. 二次开发改造把命令执行封装成可复用的数据访问层直接在业务代码里到处CreateInstance(__uuidof(Command))半年之后没人说得清哪些 SQL 被谁调用。我一般会在 Command 之上再封一层只暴露「执行、取结果、绑参」三件事。6.1 CDbCommand 的接口设计与参数绑定辅助// DbCommand.h —— 薄封装只管命令不管连接生命周期 class CDbCommand { public: explicit CDbCommand(_ConnectionPtr pConn) : m_pConn(pConn) {} // 参数化按顺序追加调用方自己保证顺序与 SQL 中 ? 一致 CDbCommand AddParam(const wchar_t* wszName, DataType eType, const _variant_t vValue); // 执行并返回记录集调用方负责 Close _RecordsetPtr Query(const wchar_t* wszSql); // 执行非查询返回受影响行数失败返回 -1 long Execute(const wchar_t* wszSql); private: void Reset(const wchar_t* wszSql); // 复用 Command 对象清参数、换文本 _ConnectionPtr m_pConn; _CommandPtr m_pCmd; }; // 关键实现复用同一个 _CommandPtr避免每轮 CreateInstance void CDbCommand::Reset(const wchar_t* wszSql) { if (m_pCmd NULL) { m_pCmd.CreateInstance(__uuidof(Command)); m_pCmd-ActiveConnection m_pConn; m_pCmd-CommandType adCmdText; m_pCmd-Prepared VARIANT_TRUE; } m_pCmd-CommandText _bstr_t(wszSql); // 参数集合手动清空比重建对象便宜得多 while (m_pCmd-Parameters-Count 0) m_pCmd-Parameters-Delete(_variant_t((long)0)); }Reset里用Delete(0)循环清空参数是因为Parameters集合没有Clear方法。Delete的参数是索引从 0 开始每次都删第一个等价于全部清掉。这里有性能考虑复用同一个 Command 对象驱动那边对 SQL 的预编译结果能命中缓存比每次新建快 20%30%具体取决于语句复杂度。改造的时候把原来散在各处的连接字符串统一收进配置把「执行 错误处理 日志」收进Execute/Query里。业务层只写 SQL 和绑参不再看见_com_error。这一步做完后面换驱动或者加连接池改动面就只剩这一层。6.2 验证空结果集、超时、异常路径怎么测封装好之后必须过三条验证缺一条都会在生产环境还债。第一条空结果集。构造一个必然查不到的条件确认Query返回的 Recordset 非空对象但EndOfFile为TRUE业务层拿到的是空列表而不是崩溃。这条最容易漏因为开发时测试数据总是有值的。第二条超时。在存储过程里加一个WAITFOR DELAY或者查一张加了锁的表验证CommandTimeout到点后抛_com_error且 catch 里能拿到错误描述。同时确认超时之后连接状态是否可用——我的处理是超时即视为连接不可信直接换新连接别试着复用。第三条异常路径的参数复位。故意让一次Execute失败比如传一个超长字符串触发截断失败之后再跑一次正常查询确认Reset把上一次的残留参数清干净了。这条我在一个批量导入功能里翻过车某一行数据超长失败后下一行继承了上一次的参数插进去两条一样的记录排查时数据库里数据看起来完全合法。从那以后我每次给 Command 加新功能都强制走一遍「正常、空、异常、再正常」这四步再复杂的参数化语句也不例外。希望帮到你。本文还有配套的精品资源点击获取
简介面向VC数据库开发初学者与需要巩固ADO基础的开发者这份实例资料聚焦ADO核心组件Command对象的使用帮助读者理解如何通过_CommandPtr智能指针在C项目中执行SQL语句、调用存储过程以及完成带参数的查询。资源包共11个文件压缩后约8KB以3个cpp源文件和3个h头文件为主体配合vcxproj、sln等Visual Studio工程配置构成可直接打开编译的TestAdo演示项目另附一份txt说明文件指向配套文章便于对照阅读。目前已有528人学习关注。项目代码围绕连接绑定、CommandText与CommandType设置、CreateParameter创建输入参数、Execute返回记录集或影响行数等环节展开并涉及事件处理与异常捕获的写法读者可据此跑通一遍完整流程再迁移到自己的数据访问模块中减少在参数类型与存储过程调用上的试错成本。1. 一个 VC 老项目里的 SQL 执行入口为什么我最后选了 _CommandPtr去年接手一个维护了七八年的 VC 客户端数据层全是_ConnectionPtr拼字符串执行 SQL改一个查询条件就要动一次格式化代码注入风险和空指针崩溃轮着来。重构时我把所有执行点收到一个口子上试过Recordset-Open、试过裸Connection-Execute最后落在_CommandPtr上——它是 ADO 三个核心对象里最适合承接「参数化 SQL 存储过程」的那一层。这个实例围绕 VC ADO 的 Command 对象展开讲清它怎么建、参数怎么绑、结果怎么取、错怎么排。适合手里有 VC/MFC 老代码、要接数据库、又不想引第三方库的人也适合刚学 ADO 只会拼 SQL 字符串、想弄明白_CommandPtr到底解决什么问题的开发者。2. 工程骨架与技术选型ADO 三个核心对象在 VC 里的落位ADO 在 VC 里不是一份源码而是一份 COM 类型库。工程要做的只有三件事把类型库导入进来生成包装类、把 COM apartment 初始化好、按对象模型把三个智能指针串起来。下面按「对象模型 → 工程配置 → 目录结构」三层拆。2.1 从 Connection 到 Recordset_CommandPtr 卡在链路中间ADO 的对象模型是一条链Connection一次会话→Command一条命令→Recordset结果集。_CommandPtr的位置很关键它既不是必需的一环也不是可随便绕过的。不带Command时写法是pConn-Execute(sql, vtRows, adCmdText)SQL 文本直接作为字符串传进去参数只能靠自己拼接。带Command时SQL 与参数分离参数通过Parameters集合单独绑定由驱动层做类型校验和转义。三条路径的取舍我一般这么判断使用场景推荐对象原因一次性简单查询、SQL 里无外部输入Connection-Execute代码最短无需额外对象开销需要带参数、反复执行的 SQL_CommandPtradCmdText参数与文本分离避免拼接与注入调用存储过程、带输出参数_CommandPtradCmdStoredProc只有 Command 能拿到输出参数与 RETURN 值大批量插入、多次复用同一语句_CommandPtr 事务语句只解析一次配合批次提交可控选_CommandPtr的真实理由不是「ADO 官方推荐」而是它能拿到RecordsAffected。在执行 UPDATE/DELETE 时Connection-Execute返回的 Recordset 是空的影响行数得从第一个参数里取而 Command 的 Execute 同样返回这个 out 参数但在参数化语句里你能确定这条行数是本次这条语句产生的不是别人拼接进来的。对象模型还有个常被忽略的点Command的ActiveConnection可以是Connection对象也可以是一个连接字符串。前者复用已有会话连接池友好后者每次执行会隐式新建连接。我一般用前者只在极少数「一次录入全表」的批处理脚本里才用后者省掉显式 Open 的代码。2.2 引入类型库msado15.dll 的 import 写法与常见编译配置VC 用#import指令把msado15.dll里的类型库翻译成.tlh/.tli两个头文件然后把_ConnectionPtr、_CommandPtr、_RecordsetPtr、_variant_t、_bstr_t这些_com_ptr_t智能指针给你。这份导入代码必须放在一个只编译一次的位置否则每个 cpp 都生成一份tlh链接期会出现重定义。// stdafx.h或预编译头中统一引入只在预编译单元里生效 #import C:\Program Files\Common Files\System\ado\msado15.dll \ no_namespace \ rename(EOF, EndOfFile) \ rename(BOF, BeginOfFile) \ rename(DeleteFile, AdoDeleteFile) \ rename(GetObject, AdoGetObject) // 参数说明 // no_namespace 不生成 ADODB 命名空间全局直接用 _CommandPtr // 若想隔离可换成 rename_namespace(ADODB)代码里写 ADODB::_CommandPtr // rename(EOF, ...) 类型库里的 EOF 属性和 stdio.h 的宏 EOF 同名不重命名必然编译报错 // rename(BOF, ...) 同上BOF 在部分 SDK 头里也有冲突 // DeleteFile/GetObject 与 Win32 API 同名一并改名避免链接歧义这段导入代码的第一个坑是路径。msado15.dll在 32 位系统上位于C:\Program Files\Common Files\System\ado\64 位系统上这个目录同样存在它是 32 位版的副本但如果你把工程编成 x64导入的还是同一份类型库文件运行期却能找到 64 位的实现这一点通常没问题。真正的风险是硬编码盘符——若工程要拷到别的机器编译建议写成相对形式或改成#import msado15.dll让编译器沿 PATH 与系统目录查找头区域。我自己的习惯是在stdafx.h里用#pragma comment(lib, ...)补 DLL 的导入库不需要#import已经生成msado15.tlh中的_com_ptr_t模板代码链接时依赖的是系统自带的msado15.dll导出表工程里不用额外加.lib。导入之后记得处理_com_ptr_t在异常下的行为。#import生成的包装类默认会_com_raise_error抛_com_error也就是异常路径。如果你维护的是老式 MFC 代码全部用返回值判错那就在导入后加一个空实现的错误处理器// 关闭 #import 生成的自动异常抛出改为手动检查 hr // 注意一旦替换掉默认处理器_com_ptr_t 的 CreateInstance 返回空指针而非抛异常 void __stdcall AdoErrorHandler(HRESULT, IErrorInfo*) {}不过我在实际项目里还是保留默认抛异常的行为外层用try/catch (_com_error)统一接。原因很实际ADO 的错误信息SQL 状态、原生错误码、Description全部挂在IErrorInfo上走异常路径才能拿到完整的ErrorMessage和Source手动判 hr 再调GetErrorInfo反而罗嗦。2.3 最小可跑工程的目录与文件清单一个能跑起来的最小工程我一般拆成四个文件职责边界清楚后面加功能不会全堆在对话框类里。AdoCommandDemo/ ├── AdoCommandDemo.sln ├── AdoCommandDemo/ │ ├── stdafx.h // #import 类型库 公共头 │ ├── stdafx.cpp // 预编译头占位保证 tlh/tli 只生成一次 │ ├── DbEnv.h / DbEnv.cpp // COM 初始化/反初始化 连接串常量 │ ├── DbCommand.h/.cpp // Command 的薄封装建对象、绑参、执行、取结果 │ └── main.cpp // 业务入口调用 DbCommand 跑三条示例 SQL └── sql/ └── init.sql // 建库建表脚本含一条示例存储过程这个结构里stdafx.cpp不是摆设。#import放在stdafx.h里编译器会在每个包含它的 cpp 里重新生成msado15.tlh/.tli但只要工程开了预编译头实际编译时只会生成一次。反过来如果项目没开预编译头又到处 include就会出现LNK2005重定义。要么开 PCH要么把#import挪进一个单独的.cpp在头文件里只声明需要的类型。COM 初始化放在DbEnv里工程主入口一开始就调用// DbEnv.cpp #include stdafx.h #include DbEnv.h bool DbEnv::Init() { // 单线程单元STA。MFC 对话框工程也可以用 AfxOleInit() 代替 HRESULT hr ::CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); // S_FALSE 表示本线程已初始化过同样算成功 return SUCCEEDED(hr); } void DbEnv::Uninit() { ::CoUninitialize(); }CoInitializeEx的 apartment 模型必须和你后续使用 ADO 的线程匹配。所有 ADO 对象都是单元线程模型一个Connection对象创建在哪个 STA 里就只能在这个 STA 里用跨线程传指针过去轻则返回RPC_E_WRONG_THREAD重则直接崩在QueryInterface里。这是我踩过的第一个血泪经验——后台导出线程里复用了主线程的_ConnectionPtr跑十分钟必崩最后改成每个工作线程自己 Open 一条连接才消停。3. 核心链路拆解CommandText、Parameters、Execute 三段式怎么写Command 的使用永远是三段给CommandText赋值、按顺序把参数 Append 进Parameters、调Execute拿结果。三段里的每一段都有坑下面按对象逐个落代码。3.1 连接对象Connection 打开、超时与连接串参数_CommandPtr自己不建连接它靠ActiveConnection绑一条已打开的Connection。连接串的写法直接决定后面 Command 能不能正常绑参。// DbCommand.cpp —— 建立并打开连接 _ConnectionPtr DbCommand::OpenConn(const char* szConn) { _ConnectionPtr pConn; // CreateInstance 走 CoCreateInstance失败会抛 _com_error pConn.CreateInstance(__uuidof(Connection)); // 连接超时单位是秒默认 30卡网时体验极差一般压到 5 pConn-ConnectionTimeout 5; // 命令超时同样以秒计0 表示无限等待千万别留 0一条慢 SQL 能把 UI 挂死 pConn-CommandTimeout 30; try { // Open 四个参数连接串、用户、密码、选项 // 连接串里已经带了 User ID/Password后两个传空即可 pConn-Open(_bstr_t(szConn), _bstr_t(L), _bstr_t(L), adConnectUnspecified); } catch (_com_error e) { // e.Description() 是驱动返回的中文描述比 HRESULT 有用得多 OutputDebugStringW(e.Description()); throw; } return pConn; }连接串里我一般显式写全这几个键缺一个就可能走默认值踩坑ProviderSQLOLEDB;Data Source127.0.0.1,1433;Initial CatalogDemoDb; User IDdemo_user;Password******;Connect Timeout5;Use Procedure for Prepare1;Data Source后面跟端口时用逗号不是冒号这点和别的驱动不一样写错了报的是「未找到或无法访问服务器」看起来像网络问题实际是连接串语法问题。Use Procedure for Prepare1是让驱动在第二次执行同一 Command 时把它转成临时存储过程参数化语句反复跑的场景下能省掉重复解析但只在语句结构稳定时生效属于可选优化。adConnectUnspecified和adConnectAsync的区别也要注意后者会立刻返回连接在后台建立此后再调Command-Execute可能拿到「对象关闭时不允许操作」。异步连接只适合做那种「先连上再显示进度条」的场景业务代码里一律用同步。3.2 无参命令CommandText 加 Execute 返回记录集的完整代码最简单的用法是不带参数把 Command 当成一个「可以复用的 SQL 容器」。这类代码在示例里到处都是但完整带错误处理的并不多。// 无参查询返回结果集 _RecordsetPtr DbCommand::QueryNoParam(_ConnectionPtr pConn, const wchar_t* wszSql) { _CommandPtr pCmd; pCmd.CreateInstance(__uuidof(Command)); pCmd-ActiveConnection pConn; // 绑定已有会话复用连接池 pCmd-CommandText _bstr_t(wszSql); pCmd-CommandType adCmdText; // 明确告诉驱动这是 SQL 文本不是表名或存储过程 pCmd-Prepared VARIANT_TRUE; // 请求驱动预编译参数化语句才有意义 _variant_t vtAffected; // 出参受影响行数查询时无意义 _RecordsetPtr pRs pCmd-Execute(vtAffected, NULL, adCmdText); if (pRs NULL) // 无结果集时返回 NULL不能直接调 Close return NULL; return pRs; }这里有个容易忽略的细节Execute的第三个参数Options和CommandType是重复的。两者同时给时以谁为准实测是Execute的 Options 优先——如果你把CommandType设成adCmdStoredProc却在Execute里传adCmdText驱动会按文本去解析存储过程名报「找不到对象」。所以要么统一在CommandType上设、Execute传adCmdUnspecified要么反过来。我的习惯是两个都写同一个值虽然冗余但一眼能看出意图。返回的_RecordsetPtr默认是只读、仅向前游标adOpenForwardOnly/adLockReadOnly。这在只遍历一次的场景下最快但如果要取RecordCount它会返回 -1——因为仅向前游标不支持计数。需要行数时不要改游标类型多一次全表扫描不划算改成在 SQL 里加COUNT(*)或者遍历计数。3.3 带参命令CreateParameter 与 Parameters-Append 的顺序约束参数化是 Command 的核心价值。ADO 的?占位符按位置绑定没有命名参数的概念Oracle 除外这是最容易翻车的地方。// 带参查询按 id 与姓名前缀过滤 _RecordsetPtr DbCommand::QueryByIdName(_ConnectionPtr pConn, long nId, const wchar_t* wszName) { _CommandPtr pCmd; pCmd.CreateInstance(__uuidof(Command)); pCmd-ActiveConnection pConn; // 占位符用 ?顺序必须与下面 Append 的顺序严格一致 pCmd-CommandText _bstr_t(LSELECT id, name, amount FROM t_order WHERE id ? AND name LIKE ?); pCmd-CommandType adCmdText; pCmd-Prepared VARIANT_TRUE; // 参数 1整型输入长度对定长类型无意义传 sizeof 只为语义清晰 pCmd-Parameters-Append( pCmd-CreateParameter(_bstr_t(Lid), adInteger, adParamInput, sizeof(long), _variant_t(nId))); // 参数 2变长宽字符输入长度是“字符数”不是字节数 // 传 0 表示让驱动按实际值推断显式传长度时超过会被截断且不报错 _bstr_t bsName wszName; pCmd-Parameters-Append( pCmd-CreateParameter(_bstr_t(Lname), adVarWChar, adParamInput, bsName.length(), _variant_t(bsName))); _variant_t vtAffected; return pCmd-Execute(vtAffected, NULL, adCmdText); }参数顺序这件事必须咬死。ADO 内部对?的解析是「第几个问号配第几个参数」CreateParameter的第一个名字参数id、name对 SQL Server 来说只是备注驱动不会拿名字去匹配。所以代码里Append的顺序和 SQL 里?的书写顺序不一致就会出现「id 拿字符串去比、name 拿数字去比对」的错位而且不报错只是查出来的行数不对。这类 bug 最难查因为 SQL 本身看起来完全正常。另一个坑是Parameters-Refresh()。有些教程会教你「先 Execute 一次让驱动自动解析参数」或者执行前调Refresh。别这么干。Refresh会清空你已经 Append 的参数重新从服务器拿一遍参数列表对于adCmdText拿回来的是一个「未命名、类型未知」的参数集合你还得再按索引去补值。参数化语句的参数一律自己 Append不要混用 Refresh。只有在调用存储过程、且不想手工写参数列表时才用 Refresh且必须在设好CommandText和CommandType之后、Execute之前只调一次。长度参数再强调一遍adVarWChar的长度是字符数。写sizeof(wchar_t) * len会让驱动认为字段长度翻倍某些驱动版本下直接报「参数长度无效」写得太短则会静默截断插入进去的字符串少几个字用户反馈「保存后名字少一半」查半小时才发现是这里。3.4 存储过程调用adCmdStoredProc、输出参数与返回值的取值方式存储过程是 Command 相对 Connection 的唯一优势场景因为只有 Command 能持有输出参数。// 调用存储过程两个输入、一个输出、一个 RETURN 值 void DbCommand::CallProc(_ConnectionPtr pConn, long nOrderId, long nDelta) { _CommandPtr pCmd; pCmd.CreateInstance(__uuidof(Command)); pCmd-ActiveConnection pConn; pCmd-CommandType adCmdStoredProc; pCmd-CommandText _bstr_t(Lsp_UpdateOrderAmount); // 只写过程名不带 exec、不带库名 // 顺序按存储过程定义输入1、输入2、输出1、RETURN pCmd-Parameters-Append( pCmd-CreateParameter(_bstr_t(Lorder_id), adInteger, adParamInput, 0, _variant_t(nOrderId))); pCmd-Parameters-Append( pCmd-CreateParameter(_bstr_t(Ldelta), adInteger, adParamInput, 0, _variant_t(nDelta))); // 输出参数长度给 0Execute 之后由服务器回填类型与值 pCmd-Parameters-Append( pCmd-CreateParameter(_bstr_t(Lnew_amount), adInteger, adParamOutput, 0)); _variant_t vtAffected; pCmd-Execute(vtAffected, NULL, adCmdStoredProc); // 取值输出参数按索引从 1 开始RETURN 值固定叫 RETURN_VALUE long nNewAmount pCmd-Parameters-GetItem(_variant_t((long)3))-Value.lVal; long nRet pCmd-Parameters-GetItem(_bstr_t(LRETURN_VALUE))-Value.lVal; // nRet 为 0 表示过程内未显式 RETURN非 0 才是业务返回码 }这里最容易错的是参数顺序里RETURN_VALUE的位置。SQL Server 的过程返回值是隐式的第一个参数但 ADO 在Parameters集合里通常把它放在最后索引等于参数个数。稳妥写法是按名字取GetItem(_bstr_t(LRETURN_VALUE))别数索引。按索引取的时候一旦有人在过程里加了参数你的代码就静默读错位置。CommandText只写过程名。写成exec sp_xxx、带上dbo.前缀或者末尾加;1在adCmdStoredProc模式下都会被当成过程名的一部分报「找不到存储过程」。这一点和某些驱动不一样从别的数据库转过来的人特别容易在这里翻车。另外adParamOutput和adParamInputOutput的区别要分清纯输出参数不需要给初值给adParamOutput既要传进又要拿回的用adParamInputOutput且必须给初值否则过程里读到的是 NULL。adParamReturnValue这个类型一般不用手动 AppendADO 在调用存储过程时会为你补一个。3.5 增删改与事务AffectedRecords 取值和 BeginTrans 三件套INSERT/UPDATE/DELETE 走的是同一条 Command 链路区别只在怎么拿执行结果。// 增删改返回实际影响的行数 long DbCommand::ExecNonQuery(_ConnectionPtr pConn, const wchar_t* wszSql, long nId, const wchar_t* wszName) { _CommandPtr pCmd; pCmd.CreateInstance(__uuidof(Command)); pCmd-ActiveConnection pConn; pCmd-CommandText _bstr_t(wszSql); pCmd-CommandType adCmdText; pCmd-Prepared VARIANT_TRUE; pCmd-Parameters-Append( pCmd-CreateParameter(_bstr_t(Lname), adVarWChar, adParamInput, (long)wcslen(wszName), _variant_t(wszName))); pCmd-Parameters-Append( pCmd-CreateParameter(_bstr_t(Lid), adInteger, adParamInput, 0, _variant_t(nId))); _variant_t vtAffected; _RecordsetPtr pRs pCmd-Execute(vtAffected, NULL, adCmdText); // 非查询语句返回的 Recordset 是 NULL显式判一下再释放 if (pRs ! NULL) pRs-Close(); // RecordsAffected 的 vt 可能是 VT_I4 也可能是 VT_NULL语句无返回统一转一次再取 long nAffected 0; if (vtAffected.vt VT_I4) nAffected vtAffected.lVal; else if (vtAffected.vt VT_NULL || vtAffected.vt VT_EMPTY) nAffected -1; return nAffected; }RecordsAffected的坑在于返回值不一定是整数。驱动在「SET NOCOUNT ON」的批处理下会给你VT_NULL直接取vtAffected.lVal不会崩但拿到的是垃圾值。必须先看vt。这个细节我在一个统计脚本里吃过亏更新 200 行日志记成 0 行排查了一下午。多条语句要么全成功要么全回滚的场景用 Connection 的事务方法包住// 事务三件套BeginTrans / CommitTrans / RollbackTrans void DbCommand::Transfer(_ConnectionPtr pConn, long nFrom, long nTo, double dAmount) { // BeginTrans 返回嵌套层数1 表示最外层 long nLevel pConn-BeginTrans(); try { ExecNonQuery(pConn, LUPDATE t_account SET balance balance - ? WHERE id ?, nFrom, L); ExecNonQuery(pConn, LUPDATE t_account SET balance balance ? WHERE id ?, nTo, L); pConn-CommitTrans(); // 两层嵌套时只有最外层 Commit 才真正提交 } catch (_com_error e) { pConn-RollbackTrans(); // 回滚必须写在 catch 里不能只靠析构 OutputDebugStringW(e.Description()); throw; } }注意RollbackTrans和CommitTrans都是 Connection 的方法不是 Command 的。Command 本身没有事务边界它只是在一个连接会话里干活。所以事务粒度只能是「一条连接」两条连接之间做不了原子操作——这也是为什么分库分表场景下 ADO 的这套原生事务不够用。还有一点事务里的 Command 如果超时CommandTimeout到点连接状态会变成「不可用」此时再调RollbackTrans可能报「连接繁忙」。超时值要设得比事务里的最长语句再宽裕一些我一般把事务内的CommandTimeout临时抬到 60 秒出作用域再还原。4. 数据往返细节字段取值、_variant_t 类型转换与中文编码Command 只负责把语句送出去、把结果集拿回来真正写业务代码时耗在取值上的时间远多于执行。这一章讲字段怎么读、类型怎么转、中文怎么不丢。4.1 Fields-GetItem 的三种索引与 NULL 判定_RecordsetPtr取字段有三种写法性能和可读性各有取舍。// 遍历结果集并取值 void DbCommand::PrintOrders(_RecordsetPtr pRs) { while (!pRs-EndOfFile) // 注意rename 之后是 EndOfFile不是 EOF { // 方式一按序号0 基最快适合列顺序固定且自己写的 SQL _variant_t vId pRs-Fields-GetItem(_variant_t((long)0))-Value; // 方式二按字段名可读性最好适合列多、多人维护的查询 _variant_t vName pRs-Fields-GetItem(_bstr_t(Lname))-Value; // 方式三先拿 Field 对象再用下标需要判断字段是否存在时用这个 if (pRs-Fields-GetItem(_bstr_t(Lamount)) ! NULL) { _variant_t vAmount pRs-Fields-GetItem(_bstr_t(Lamount))-Value; } // NULL 判定必须写在取值之前vt 是 VT_NULL 时字段里没有值 if (vName.vt ! VT_NULL vName.vt ! VT_EMPTY) { CString strName (LPCTSTR)_bstr_t(vName); } pRs-MoveNext(); } }GetItem传long时必须包_variant_t((long)0)。直接写GetItem(0)会因为_variant_t的构造重载把 0 解释成VT_I2或指针空值编译可能过运行时拿到的是第 0 个字段或者直接抛「参数类型不正确」。这种隐式转换错误编译器不提示属于典型的玄学 bug。按名字取字段比按序号慢多少实测在 20 列、10 万行的遍历里差大概 5%8%。真正贵的是Value的VARIANT拷贝不是名字查找。所以除非是超大批量的导出我一般按名字取可维护性优先。EndOfFile的判断也有讲究。空结果集情况下EndOfFile一开始就是TRUE但如果游标被移到末尾之后又调MoveNext不同驱动行为不一致有的会抛异常。稳妥写法是while (pRs ! NULL !pRs-EndOfFile)并且MoveNext之后不再做别的判断。4.2 _variant_t / _bstr_t 的生命周期与类型强转_variant_t是VARIANT的 RAII 包装构造时 Init、析构时 Clear。这意味着它不能随便拷来拷去——每次拷贝都是一次VariantCopy深拷贝字符串。循环里写_variant_t v pRs-Fields-GetItem(...)-Value;每轮都要拷一次10 万行就是 10 万次堆分配能明显看到 CPU 打满但磁盘无 IO 的怪象。要转成基本类型别直接取.lVal尤其是adNumeric/adDecimal这类字段VARIANT的 vt 可能不是VT_I4而是VT_DECIMAL或VT_BSTR。统一走ChangeType更安全// 安全取值先 ChangeType 再取避免 vt 不匹配拿到垃圾值 long DbCommand::GetLong(_variant_t v) { if (v.vt VT_NULL || v.vt VT_EMPTY) return 0; if (v.vt VT_I4) return v.lVal; // 已经是整数直接取省一次转换 _variant_t vTmp v; if (FAILED(vTmp.ChangeType(VT_I4))) // 转换失败返回错误码不抛异常 return 0; return vTmp.lVal; } CString DbCommand::GetStr(_variant_t v) { if (v.vt VT_NULL || v.vt VT_EMPTY) return CString(); _bstr_t bs v; // _variant_t 到 _bstr_t 有隐式转换 return CString((LPCTSTR)bs); }_bstr_t的坑在长度上_bstr_t内部维护的是带长度前缀的 BSTR可以包含\0而(LPCTSTR)强转到CString时会按\0截断。这不是常见场景但如果字段存的是二进制转出来的字符串就会出现「取出来少一半」的现象看着像数据库丢了数据。最后一个隐式转换雷区_com_ptr_t的operator-在指针为空时直接返回空随后访问成员会崩。CreateInstance之后一定确认非空尤其是把它当成员变量缓存、启动时创建失败被吞掉异常的情况。4.3 中文与宽字符连接串、N 前缀和 CString 转换中文问题的根子在两处参数值怎么传、SQL 文本里的字面量怎么传。第一处是工程字符集。VC 工程如果设成「多字节字符集」CString是CStringA传给_bstr_t时走的是 ANSI→UTF-16 的转换用的是系统代码页。代码页不对比如数据库里是 UTF-8 存过来的中文就变问号。要么工程统一设成「Unicode 字符集」要么在转换时显式指定代码页// 从 UTF-8 字节流转成宽字符避免依赖系统代码页 CStringW DbCommand::Utf8ToW(const char* szUtf8) { int nLen ::MultiByteToWideChar(CP_UTF8, 0, szUtf8, -1, NULL, 0); CStringW strRet; ::MultiByteToWideChar(CP_UTF8, 0, szUtf8, -1, strRet.GetBuffer(nLen), nLen); strRet.ReleaseBuffer(); return strRet; }第二处是 SQL 里的中文字面量。参数化语句不存在这个问题值走参数通道不拼进 SQL但如果你在CommandText里写了WHERE name LIKE %张%就必须在字符串前加NN%张%。不加N的话SQL Server 会把它当 varchar 解析用当前库的排序规则做隐式转换跨排序规则的库之间直接变乱码。这个坑在做过一次库迁移之后我彻底记住了。第三处是参数类型。中文必须用adVarWChar不要用adVarChar。后者会走 ANSI 转换服务端代码页不匹配就丢字。对应的用adVarWChar时长度参数是字符数wcslen就行用adVarChar时一个中文字在 GBK 下占 2 字节在 UTF-8 下占 3 字节写strlen会因为字节数不够被截断。还有个隐蔽的LIKE查询里的通配符。参数化时写LIKE ?参数值本身要带%即_bstr_t(L%张%)。如果写成LIKE %?%问号会被当成普通字符永远查不到。这个和 3.3 节的顺序错位一样属于「语法都对、结果不对」的类型。5. 避坑与排查Command 对象调试时最常见的五类翻车现场ADO 的错误信息大多被_com_error包了一层直接看hr很难定位。下面五条是我这两年修过的、能在十分钟内定位的典型问题每条按现象、原因、解决写。5.1 现象Execute 报「对象关闭时不允许操作」代码里明明 Open 过原因基本是两件事之一。一是ActiveConnection赋的是连接字符串而不是已打开的Connection对象Execute时 ADO 内部临时建连接完了马上关此时再访问 Recordset 就提示关闭。二是Connection对象在另一个线程打开的跨 apartment 使用。解决把pCmd-ActiveConnection pConn;改成pCmd-ActiveConnection _variant_t((IDispatch*)pConn);确保按 IDispatch 传指针而不是走了连接串的转换路径。跨线程的改法是每个线程各自CoInitializeEx 各自 Open绝不共享_ConnectionPtr。另外检查Connection-Stateif (pConn-State adStateOpen)才往下走否则先 Open。这条检查我后来直接封进了OpenConn省得每次怀疑。5.2 现象编译报error C2059: 语法错误:“常量”指向EOF那一行原因msado15.dll类型库里有一个名为EOF的属性和stdio.h里的宏EOF值为 -1撞了。预处理阶段宏展开把EOF换成-1语法就崩了。解决#import时加rename(EOF, EndOfFile)。如果已经有很多代码在用pRs-EOF两种过渡方式一是在导入后手动#undef EOF再补一个#define EOF EndOfFile能编译过但很脏后续维护的人会找不到定义二是全量替换成EndOfFilerename是正解。BOF同理一并 rename不然腾出手来还会再撞一次。5.3 现象存储过程调用返回「参数 xxx 未提供值」或输出参数读到 0原因CreateParameter的名字和存储过程里的参数名不一致而这个不一致在adCmdStoredProc下是致命的。普通 SQL 的?占位符不看名字存储过程看。另外append 了adParamOutput但没给adParamInputOutput的初值过程里读到 NULL做加法后仍是 NULL最后回填回来的就是 0。解决参数名严格对齐过程定义包括前缀输出参数确认是纯输出还是输入输出输入输出必须给初值。排查时打开服务端语句审计看 ADO 实际发过去的过程调用文本参数个数和类型一眼就能对出来。不要靠猜也不要靠Parameters-Refresh那个会把参数集合顺序重排。5.4 现象大批量插入时内存持续上涨最后抛_com_error 0x8007000E内存不足原因循环里每轮都新建_CommandPtr且没有释放或者把_variant_t塞进 STL 容器后一直没清。_com_ptr_t是引用计数但_variant_t持有BSTR时也占堆内存。解决Command 对象提到循环外创建参数值用Parameters-GetItem(n)-Value _variant_t(...)就地赋值比每轮重新Append快一个数量级也不会让参数集合越堆越大。循环内的中间变量用花括号限定作用域让析构及时发生。再配一个SQLBulkOperations或批量批处理每 500 条 Execute 一次10 万行插入从几分钟降到几秒。批量提交记得包事务否则每次 Execute 都刷一次日志磁盘 IO 会顶满。5.5 现象查询条件里明明有数据SQL 在客户端执行能查到代码里查不到原因参数类型与字段类型不匹配走了隐式转换。典型是字段nvarchar参数传adVarChar跨代码页比较时索引失效甚至比较结果不等或者字段是datetime参数传的是字符串格式随区域设置变化。解决按字段类型精确指定参数类型nvarchar配adVarWChardatetime配adDBTimeStamp且值用_variant_t的VT_DATEdecimal配adNumeric并显式给NumericScale。查不到的时候先不要怀疑 SQL把CommandText和参数值逐个打日志再到数据库端用同样的值手工执行一次——差异立刻就能看出来。这一步听着笨但它省下的时间比任何调试技巧都多。6. 二次开发改造把命令执行封装成可复用的数据访问层直接在业务代码里到处CreateInstance(__uuidof(Command))半年之后没人说得清哪些 SQL 被谁调用。我一般会在 Command 之上再封一层只暴露「执行、取结果、绑参」三件事。6.1 CDbCommand 的接口设计与参数绑定辅助// DbCommand.h —— 薄封装只管命令不管连接生命周期 class CDbCommand { public: explicit CDbCommand(_ConnectionPtr pConn) : m_pConn(pConn) {} // 参数化按顺序追加调用方自己保证顺序与 SQL 中 ? 一致 CDbCommand AddParam(const wchar_t* wszName, DataType eType, const _variant_t vValue); // 执行并返回记录集调用方负责 Close _RecordsetPtr Query(const wchar_t* wszSql); // 执行非查询返回受影响行数失败返回 -1 long Execute(const wchar_t* wszSql); private: void Reset(const wchar_t* wszSql); // 复用 Command 对象清参数、换文本 _ConnectionPtr m_pConn; _CommandPtr m_pCmd; }; // 关键实现复用同一个 _CommandPtr避免每轮 CreateInstance void CDbCommand::Reset(const wchar_t* wszSql) { if (m_pCmd NULL) { m_pCmd.CreateInstance(__uuidof(Command)); m_pCmd-ActiveConnection m_pConn; m_pCmd-CommandType adCmdText; m_pCmd-Prepared VARIANT_TRUE; } m_pCmd-CommandText _bstr_t(wszSql); // 参数集合手动清空比重建对象便宜得多 while (m_pCmd-Parameters-Count 0) m_pCmd-Parameters-Delete(_variant_t((long)0)); }Reset里用Delete(0)循环清空参数是因为Parameters集合没有Clear方法。Delete的参数是索引从 0 开始每次都删第一个等价于全部清掉。这里有性能考虑复用同一个 Command 对象驱动那边对 SQL 的预编译结果能命中缓存比每次新建快 20%30%具体取决于语句复杂度。改造的时候把原来散在各处的连接字符串统一收进配置把「执行 错误处理 日志」收进Execute/Query里。业务层只写 SQL 和绑参不再看见_com_error。这一步做完后面换驱动或者加连接池改动面就只剩这一层。6.2 验证空结果集、超时、异常路径怎么测封装好之后必须过三条验证缺一条都会在生产环境还债。第一条空结果集。构造一个必然查不到的条件确认Query返回的 Recordset 非空对象但EndOfFile为TRUE业务层拿到的是空列表而不是崩溃。这条最容易漏因为开发时测试数据总是有值的。第二条超时。在存储过程里加一个WAITFOR DELAY或者查一张加了锁的表验证CommandTimeout到点后抛_com_error且 catch 里能拿到错误描述。同时确认超时之后连接状态是否可用——我的处理是超时即视为连接不可信直接换新连接别试着复用。第三条异常路径的参数复位。故意让一次Execute失败比如传一个超长字符串触发截断失败之后再跑一次正常查询确认Reset把上一次的残留参数清干净了。这条我在一个批量导入功能里翻过车某一行数据超长失败后下一行继承了上一次的参数插进去两条一样的记录排查时数据库里数据看起来完全合法。从那以后我每次给 Command 加新功能都强制走一遍「正常、空、异常、再正常」这四步再复杂的参数化语句也不例外。希望帮到你。本文还有配套的精品资源点击获取
