ADO2.20 Class 封装实战：从 msado20.tlb 导入到可维护数据访问层

简介：ADO2.20 Class 是一套面向 Visual C++ 开发者的 ActiveX Data Objects 类库，由非中文开发者在 CodeProject 上发布，旨在简化 VC 程序对 SQL Server、Oracle、Access 等数据源的访问，让开发者无需深入底层 ADO 接口即可快速集成数据库操作。资源包共 3 个文件，包含 1 个 cpp 实现文件、1 个 h 头文件以及 1 个 mht 说明文档，压缩包约 105KB，体积轻巧便于直接加入工程。其中头文件提供类定义与函数声明，cpp 文件封装了 Connection、Command、Recordset 等核心对象的常用操作，mht 文档则保留了原版使用说明与示例，方便对照理解。目前已有 124 人学习下载，适合不熟悉 ADO 或需要快速开发数据库应用的 VC 开发者参考，可借此掌握连接数据库、执行查询、遍历结果集等关键环节，并在此基础上按自身业务需求扩展封装。

1. ADO2.20 Class：老代码里绕不开的那层封装

接手一套跑了七八年的 MFC 或 VB6 遗留系统时，你大概率会在某个头文件里撞见CADORecordset、_ConnectionPtr、_CommandPtr这类名字，紧接着就是一句#import "C:\Program Files\Common Files\System\ado\msado20.tlb"。这就是 ADO2.20 Class 的真实出场方式——它不是某个新框架，而是微软数据访问组件 2.20 版本通过类型库导入后生成的一整套 COM 包装类。很多人第一次搜这个词，是因为编译报错、智能提示失效，或者想把老项目迁到新环境却发现连接字符串怎么改都不对。它解决的核心问题只有一个：让 C++ 或 VB 代码用接近面向对象的方式去操作数据库，而不用手写底层 COM 的QueryInterface和AddRef。适合谁看？维护存量系统的工程师、做工业上位机或财务软件的开发者，以及需要把 ADO 逻辑逐步替换成现代数据访问层的人。这一章先把这层封装到底是什么讲清楚，后面再动手。

2. 从 msado20.tlb 到可用类：导入机制与最小可跑示例

2.1 类型库导入到底生成了什么

ADO2.20 Class 的本质是 COM 类型库（Type Library）经过编译器处理后产生的一组智能指针包装。以 Visual C++ 为例，#import指令会读取msado20.tlb，在编译中间目录生成msado20.tlh和msado20.tli两个文件。.tlh里是接口声明、枚举和_com_ptr_t派生类，.tli里是内联函数实现。你写的_ConnectionPtr实际展开后是_com_ptr_t<_com_IIID<ADODB::_Connection, &__uuidof(ADODB::_Connection)>>，它替你管理引用计数，析构时自动调用Release。

这里有个容易被忽略的点：ADO 的类名前面带下划线，比如_ConnectionPtr、_RecordsetPtr、_CommandPtr，而下划线开头的标识符在 C++ 里通常保留给实现，微软这么命名是为了避免和用户代码冲突。导入时还会生成ADODB命名空间，所以完整写法是ADODB::_ConnectionPtr，只是多数老代码用using namespace ADODB;省掉了前缀。

为什么用#import而不是直接#include某个头文件？因为 ADO 是 COM 组件，接口定义存在二进制类型库里，#import是编译器读取类型库并生成 C++ 友好声明的标准手段。这也解释了为什么换一台机器、换一个 ADO 版本，代码可能编译不过——类型库路径和版本对不上。

2.2 最小可跑的连接与查询代码

下面这段代码在 VS2015 及以上、x86 或 x64 下都能编译，前提是系统已注册 ADO 2.20 或更高版本（Windows 自带，通常无需单独安装）。

// 引入 ADO 2.20 类型库，no_namespace 可避免命名空间污染 // 若想用 ADODB:: 前缀，去掉 no_namespace 即可 #import "C:\Program Files\Common Files\System\ado\msado20.tlb" \ rename("EOF", "adoEOF") no_namespace #include <iostream> int main() { // 初始化 COM，MFC 项目里通常已由框架完成 ::CoInitialize(NULL); try { // 创建连接对象，_ConnectionPtr 是智能指针包装 _ConnectionPtr pConn(__uuidof(Connection)); // 连接字符串：Provider 指定驱动，Data Source 指定文件或服务器 pConn->ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;" "Data Source=D:\\data\\demo.mdb;"; // 超时设为 5 秒，避免网络库长时间卡死 pConn->ConnectionTimeout = 5; pConn->Open("", "", "", adConnectUnspecified); // 创建记录集并执行查询 _RecordsetPtr pRs(__uuidof(Recordset)); pRs->Open("SELECT id, name FROM users", pConn.GetInterfacePtr(), adOpenStatic, adLockReadOnly, adCmdText); // 遍历结果，adoEOF 是重命名后的常量，避免和文件 EOF 冲突 while (!pRs->adoEOF) { long id = pRs->Fields->Item["id"]->Value; _bstr_t name = pRs->Fields->Item["name"]->Value; std::cout << id << " : " << (const char*)name << std::endl; pRs->MoveNext(); } pRs->Close(); pConn->Close(); } catch (_com_error& e) { // _com_error 封装了 HRESULT 和错误描述 std::cerr << "COM error: " << (const char*)e.Description() << std::endl; } ::CoUninitialize(); return 0; }

逻辑说明：先CoInitialize初始化 COM 库，这是任何 COM 组件使用前的必要步骤。_ConnectionPtr pConn(__uuidof(Connection))利用_com_ptr_t的构造函数创建实例，__uuidof取出接口的 GUID。ConnectionString里的Provider决定用哪个 OLE DB 驱动，Access 用Microsoft.Jet.OLEDB.4.0，SQL Server 用SQLOLEDB或MSOLEDBSQL。Open的第四个参数adConnectUnspecified表示同步打开。

参数说明：ConnectionTimeout单位是秒，默认 15，设太小会在慢网络上误报超时。pRs->Open的五个参数依次是 SQL 文本、活动连接、游标类型、锁类型、命令类型。adOpenStatic是静态游标，适合只读遍历；adLockReadOnly表示不加锁，减少对数据库的争用。adCmdText告诉 ADO 第一个参数是 SQL 语句而不是表名或存储过程。

rename("EOF", "adoEOF")这行很关键。ADO 类型库里有个EOF属性，但 C++ 标准库的<iostream>里也有EOF宏，不重命名就会冲突，报一堆看不懂的错。这是血泪经验，第一次遇到能查半天。

3. 连接字符串、游标与锁：三个决定成败的参数组

3.1 连接字符串的 Provider 选择与常见写法

连接字符串是 ADO2.20 Class 里最容易翻车的地方，因为它不是 C++ 语法问题，而是运行时才暴露。Provider 选错，报「未找到提供程序」；Data Source 路径写错，报「找不到文件」；权限不足，报「无法启动应用程序」。

Access 2007 之后的.accdb必须用 ACE 驱动，而 ACE 驱动默认不随系统安装，需要单独装 Access Database Engine。这里有个经典坑：装了 64 位 ACE 驱动，但项目编译成 32 位，运行时照样报「未找到提供程序」。位数必须匹配，这是硬约束。

SQL Server 的连接字符串通常还要带Initial Catalog指定库名，以及User ID和Password，或者用Integrated Security=SSPI走 Windows 身份验证。我一般把连接字符串放在配置文件或注册表里，不硬编码在源码中，方便现场改。

3.2 游标类型怎么选：adOpenStatic 还是 adOpenDynamic

游标类型决定记录集如何与数据源交互，直接影响性能和功能。

adOpenForwardOnly是最快的，只能向前遍历，适合一次性导出数据。adOpenStatic是静态副本，打开后数据固定，支持RecordCount和前后移动，适合报表和只读列表。adOpenDynamic能看到其他用户的增删改，但开销大，且不是所有 Provider 都支持。adOpenKeyset介于两者之间，能看到修改但看不到新增。

多数业务场景用adOpenStatic就够了。如果你发现RecordCount返回 -1，多半是用了adOpenForwardOnly，因为这种游标不维护总数。想拿总数又不想用静态游标，可以单独执行一条SELECT COUNT(*)。

锁类型方面，adLockReadOnly只读不加锁，性能最好。adLockOptimistic是乐观锁，只在Update时锁定，适合冲突少的场景。adLockBatchOptimistic配合UpdateBatch批量提交，能显著减少网络往返。adLockPessimistic是悲观锁，一打开就锁记录，容易死锁，除非明确需要，否则别用。

3.3 用 Command 对象传参，别拼字符串

直接拼 SQL 字符串有两个问题：一是注入风险，二是日期和字符串的引号处理容易出错。ADO2.20 Class 提供了_CommandPtr和Parameters集合。

_CommandPtr pCmd(__uuidof(Command)); pCmd->ActiveConnection = pConn; // 绑定已打开的连接 pCmd->CommandText = "UPDATE users SET name = ? WHERE id = ?"; pCmd->CommandType = adCmdText; // 按顺序追加参数，? 占位符按位置对应 pCmd->Parameters->Append( pCmd->CreateParameter("name", adVarWChar, adParamInput, 50, _variant_t("张三"))); pCmd->Parameters->Append( pCmd->CreateParameter("id", adInteger, adParamInput, sizeof(long), _variant_t((long)1001))); pCmd->Execute(NULL, NULL, adExecuteNoRecords); // 不返回记录集

CreateParameter的五个参数是参数名、数据类型、方向、大小、值。adVarWChar对应宽字符串，adInteger对应 32 位整数。adExecuteNoRecords告诉 ADO 这条命令不返回结果集，省去创建 Recordset 的开销。参数顺序必须和 SQL 里?的顺序一致，ADO 不按名字匹配，这点和某些 ORM 不同。

4. 避坑与排查：ADO2.20 Class 最常见的五类翻车

4.1 编译报错「foward typedef of the class does not have a definition」

现象：编译时提示某个类只有前向声明没有定义，通常出现在#import之后。原因：msado20.tlb里某些接口依赖其他类型库，编译器没有自动导入。解决：在#import前加上#import "msado15.dll"或确保msado20.tlb路径正确，并在项目属性里把Common Files\System\ado加入附加包含目录。如果还不行，改用#import "msado15.dll" no_namespace rename("EOF","adoEOF")，让编译器从 DLL 里读类型库。

4.2 运行时报「class not registered」或「未找到提供程序」

现象：程序启动或打开连接时弹出 COM 错误，HRESULT 是0x80040154。原因：目标机器没注册对应的 OLE DB Provider，或者 32/64 位不匹配。解决：先确认系统位数和程序位数一致，再检查注册表HKEY_CLASSES_ROOT\CLSID下是否有对应 Provider 的 GUID。Access 的 ACE 驱动要单独下载安装，装完重启。SQL Server 的MSOLEDBSQL也需要单独安装，系统自带的SQLOLEDB已弃用但多数场景仍可用。

4.3 遍历记录集时Fields->Item["name"]抛异常

现象：循环里取字段值，偶尔抛_com_error，描述是「在对应所需名称或序数的集合中，未找到项目」。原因：字段名拼写错误，或者 SQL 里用了别名但代码里写的是原字段名。解决：用序号代替字段名，Fields->Item[long(1)]->Value，序号从 0 开始。或者先用pRs->Fields->GetItem("name")判断是否为空。另外注意大小写，虽然多数 Provider 不区分，但某些驱动区分。

4.4 大量插入时速度慢到无法接受

现象：循环里逐条INSERT，一万条要跑几分钟。原因：每条Execute都是一次网络往返，且默认自动提交事务。解决：用_ConnectionPtr::BeginTrans开启事务，批量插入后CommitTrans，能把速度提升一个数量级。更好的做法是用adLockBatchOptimistic打开记录集，AddNew一批后调UpdateBatch。如果数据量极大，考虑用Command对象配合adExecuteNoRecords逐条执行，但务必包在事务里。

4.5 程序退出时崩溃在Release或CoUninitialize

现象：主逻辑跑完，退出时访问违例。原因：COM 对象析构顺序不对，或者CoUninitialize调用时还有未释放的接口。解决：确保所有_ConnectionPtr、_RecordsetPtr在CoUninitialize之前离开作用域，或者显式调用Close并置空。MFC 项目里AfxOleInit已经处理了初始化，不要重复调CoInitialize。如果用了多线程，每个线程都要单独CoInitialize，COM 套间模型是线程相关的。

5. 把 ADO2.20 Class 包一层：从散落代码到可维护的数据访问层

老项目里 ADO 代码往往散落在各个按钮响应函数里，连接字符串复制粘贴，异常处理各写各的。我一般会抽一个薄封装，把连接管理、参数化查询和错误转换收拢。下面这个类不是完整框架，但足够让后续维护省心。

// AdoHelper.h：轻量封装，头文件即用 #pragma once #import "C:\Program Files\Common Files\System\ado\msado20.tlb" \ rename("EOF", "adoEOF") no_namespace class AdoHelper { public: // 构造时传入连接字符串，析构自动关闭 explicit AdoHelper(const std::string& connStr) { m_conn.CreateInstance(__uuidof(Connection)); m_conn->ConnectionTimeout = 10; m_conn->Open(connStr.c_str(), "", "", adConnectUnspecified); } ~AdoHelper() { if (m_conn && m_conn->State == adStateOpen) m_conn->Close(); } // 执行不返回结果集的语句，返回受影响行数 long Execute(const std::string& sql) { _variant_t affected; m_conn->Execute(sql.c_str(), &affected, adExecuteNoRecords); return affected.lVal; } // 查询并返回记录集，调用方负责遍历和关闭 _RecordsetPtr Query(const std::string& sql) { _RecordsetPtr rs = m_conn->Execute(sql.c_str(), NULL, adCmdText); return rs; } private: _ConnectionPtr m_conn; };

逻辑说明：构造函数里CreateInstance创建连接对象，Open打开。析构函数检查状态后关闭，避免连接泄漏。Execute用_variant_t接收受影响行数，adExecuteNoRecords表示不返回记录集。Query直接返回_RecordsetPtr，利用智能指针的引用计数，调用方用完自动释放。

参数说明：连接字符串建议从配置读取，不要写死在类里。ConnectionTimeout设 10 秒是折中值，局域网够用，跨网段可适当加大。Execute返回的affected.lVal对UPDATE、DELETE有效，对SELECT无意义。

封装之后，业务代码里不再出现_com_ptr_t和CoInitialize，异常统一在边界处转成业务错误码。迁移到新数据访问层时，也只需要替换AdoHelper的实现，调用方不动。

验证封装是否可靠，有个简单办法：写一个循环，连续执行一千次查询和更新，观察内存是否稳定、连接数是否泄漏。用任务管理器看句柄数，如果持续上涨，多半是某个_RecordsetPtr没释放。我自己的习惯是，任何返回_RecordsetPtr的函数，调用方必须在同一作用域内Close，或者用try/catch包住确保释放。这个习惯帮我省了无数次半夜排查崩溃的时间。希望帮到你。

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