简介：面向商业开发场景的 ADO 源代码示例包 Ado_Aok_demo.zip，聚焦微软 ActiveX Data Objects 在 C++ 工程中的实际应用，适合需要在财务、库存、客户关系管理等业务系统中完成数据库连接的开发者参考学习。压缩包共收录 26 个文件，以八个头文件与六个 C++ 源文件为核心，辅以图标、RC 资源、类型库文件及 Visual C++ 工程配置，整体体积约 41KB，结构清晰，便于按 Visual C++ 工程方式打开研读。示例工程 AdoTest 覆盖 ADO 的典型使用流程：从连接管理、SQL 命令执行、结果集遍历，到参数化查询、事务控制与错误处理，并展示 AdoWrapper 封装类与 msado15 类型库的配合方式，帮助理解如何在商业程序中封装、复用数据库访问逻辑。源码中还包含完整的应用框架与辅助代码，可直观对照头文件声明、实现细节以及资源脚本之间的调用关系。压缩包已有 126 人浏览学习，适合希望快速掌握数据库编程常用套路并借鉴封装思路的初中级 C++ 开发者。
1. 拿到的ADO源码，别急着解压就跑
一个在工厂做设备管理系统维护的开发者，最怕的就是报表模块出问题。某次凌晨两点，产线报工数据写不进去，他翻开前任留下的代码，发现整个系统访问数据库的方式，全压在一个叫 Ado_Aok_demo 的封装源码里——连接串在这改、记录集在这开、事务在这提交。那一刻他才明白，这种看似不起眼的 ADO 封装包，才是老系统的命根子。这篇文章要拆的，就是这个标题背后的东西：ADO 是什么、这个 demo 包该怎么用、参数怎么调，以及哪些坑你早晚会踩。
标题里的 ADO 是微软推出的数据访问接口，全称 ActiveX Data Objects，它不直接连数据库，而是通过 OLE DB 提供程序访问各种数据源。这个 Ado_Aok_demo 从命名上看，是一个封装好的 ADO 示例工程，里面应该有连接管理、记录集操作、增删改查的封装代码。它的适用人群很明确：还在维护 VB6、VBA、ASP 老系统的工程师，以及新项目里需要轻量访问数据库、不想上重型 ORM 的开发者。读懂它，你就能在半小时内接手任何一份 ADO 遗留代码。
2. 从Connection到Recordset：ADO的核心对象与封装思路
2.1 三个必懂对象：连接、命令、结果集
ADO 体系里日常打交道最多的就是三个对象：Connection 负责建立会话，Command 负责执行指令，Recordset 负责承载结果。这三者的关系可以类比成打电话：Connection 是拨号建立通话，Command 是对着话筒说了一句"查一下本月产量"，Recordset 是对方报回来的那串数字。新手指最容易犯的错误，是把这三者混着用，比如用 Connection 的 Execute 方法去执行带参数的查询，导致每次执行都要重编译 SQL 语句，性能打折扣。
Dim conn As ADODB.Connection Dim cmd As ADODB.Command Dim rs As ADODB.Recordset Set conn = New ADODB.Connection conn.ConnectionString = "Provider=SQLOLEDB;Data Source=localhost;Initial Catalog=MesDB;User ID=sa;Password=123456" conn.Open Set cmd = New ADODB.Command Set cmd.ActiveConnection = conn cmd.CommandText = "SELECT * FROM t_WorkOrder WHERE FStatus = ?" cmd.Parameters.Append cmd.CreateParameter("@status", adInteger, adParamInput, , 1) Set rs = cmd.Execute这段代码展示了标准的三步链路：先建连接，再建命令并绑定连接，最后执行取结果集。注意代码里 CreateParameter 显式声明了参数类型为 adInteger，这一步非常关键——如果你省略参数类型，ADO 有时会把整型参数推断成 adVarChar，导致索引失效或类型转换报错。Command 对象的好处是，同样的 SQL 第二次执行时，数据库可以直接复用执行计划，不用重新解析语法树。
Recordset 则有自己的打开方式。很多封装库喜欢用 rs.Open 而不是 cmd.Execute，因为 Recordset 能直接控制游标类型和锁类型：
Set rs = New ADODB.Recordset rs.CursorLocation = adUseClient rs.Open "SELECT * FROM t_WorkOrder WHERE FStatus = 1", conn, adOpenStatic, adLockOptimisticCursorLocation 设置成 adUseClient 后，结果集数据会整体拉到客户端内存里，关闭连接后还能继续遍历，这种模式特别适合离线处理几十万行以内的数据。但代价是内存占用高，且数据是快照，别人在那之后提交的修改你看不见。服务端游标 adUseServer 则相反，数据按需读取，实时性高，但连接必须一直保持打开。这两个选项没有绝对好坏，只有场景是否匹配。
2.2 字段对象与记录集导航：判断边界比遍历本身重要
Recordset 打开之后，你面对的是一个由行和列组成的逻辑表格。拿到某个字段的值，最直观的写法是 rs("FName")，但这种方式底层每次都要做一次字段名到索引的映射，循环十万次就慢了。更好的做法是先取字段引用，或者直接拿索引。
Do While Not rs.EOF Debug.Print rs.Fields("FName").Value rs.MoveNext Loop这段遍历逻辑的核心在于两个边界判断：EOF 和 BOF。EOF 为 True 表示记录指针已经在最后一行之后，BOF 表示在第一行之前。新手最容易踩的是先 MoveFirst 再判断 EOF，结果发现记录集里没有数据时，两个标志同时为 True，死循环直接空转。正确的空集判断在打开之后就做一次：
If rs.EOF And rs.BOF Then MsgBox "没有符合条件的记录" Exit Sub End If封装库通常会把这个逻辑归一成类似 GetRows 之类的行读取函数，一次性把数据搬进二维数组，这样循环里连 MoveNext 都省了，速度提升显而易见。代价是行越多内存压力越大，建议单次超过五万行就不要这么干。
2.3 Aok_demo 这类封装库的设计套路：接口窄，内部才灵活
我见过不少 ADO 封装库，命名各有不同，但设计套路高度一致：对外只暴露三五个方法，比如 ExecuteSql、GetRecordset、BeginTrans，内部把连接串管理、错误处理、对象释放全部吞掉。这么做的好处是业务层代码可以忘掉 ADO 的存在，只需要跟字符串和数组打交道。缺点也很明显——封装层一旦出错，排查起来要穿过两层代码，日志如果不完整，问题定位像大海捞针。
Public Function ExecuteSql(ByVal sql As String) As Boolean Dim conn As ADODB.Connection Set conn = New ADODB.Connection conn.ConnectionString = GetConnectionString() conn.Open conn.Execute sql, , adCmdText ExecuteSql = True conn.Close Set conn = Nothing End Function这个函数把连接过程缩成一行调用，调用方不用关心 Provider 是什么、连接超时设多少。但注意，这个简单版本有两个隐患：没有错误处理，SQL 一旦出错函数直接崩；每次调用都新建连接再释放，高频场景下开销不小。成熟一点的封装会加上连接池管理，或者至少用 On Error 包一层。
参数设计上，一个好用的封装库会在函数签名里带上 Timeout 和 CommandType。Timeout 控制单条 SQL 的执行上限，默认 30 秒对于大报表不够用；CommandType 显式声明 adCmdText，能省掉 ADO 去猜这是 SQL 语句还是存储过程名的时间。这个设计思路你在读任何 ado 源码包时都可以对照看：它有没有把活连接的数量控制住，有没有把异常变成可读信息，有没有提供备用的直连通道。
3. 把Aok_demo在自己的工程里跑通：配置、调用与验证
3.1 引入 ADO 类型库：版本选择与引用配置
用 VB6 打开一个工程，要使用 ADO，第一步是勾选引用。菜单路径是"工程-引用"，在列表里找 Microsoft ActiveX Data Objects 6.1 Library 或 2.8 Library。选择哪个版本取决于目标机器的运行库环境，Win7 以上的系统自带 6.1 的运行库，但老系统的依赖往往停在 2.8 甚至 2.7。建议做法是引用低版本（如 2.8），因为运行时是向后兼容的，高版本环境照样能跑；反过来，你在高版本环境编译，部署到只有老运行库的机器上就会报"未注册的组件"。
在 VBA 里，路径不是"工程-引用"而是 VBE 的"工具-引用"。但很多从 VB 转 VBA 的开发者容易忽略一件事：VBA 的信任设置。Excel 里即使引用勾成功，代码一运行就被宏安全拦截，这种属于环境问题，不是 ADO 的问题。排查的时候先确认引用项前面没有"丢失"字样。如果引用的文件路径指向一个不存在的 DLL，这个引用项会置灰且带感叹号，一定要重新勾选正确的类型库。
如果不想依赖引用配置，还有一种迟绑定写法：用 CreateObject 创建对象，只传一个 ProgID 字符串，比如 "ADODB.Connection"。这种方式的优点是不用操心引用冲突，代码拿到任何机器都能跑；缺点是没有智能提示，写代码靠记忆，而且运行时错误要等到执行到那一行才暴露。我的习惯是，工具类脚本用迟绑定图省心，正式工程一律强引用求稳。
3.2 第一个完整例子：查数据、改数据、写日志一步走
当你拿到一份 ADO 示例项目，第一件事不是去数据库里跑正式表，而是先连一个本地的测试库做冒烟验证。下面这个例子，我建议你就照着建一个数据库和一张表：表名 t_Employee，字段 FID 自增主键、FName 文本、FSalary 数字。验证代码要跑通连接、查询、更新、日志四件事。
Public Sub DemoStep() Dim conn As ADODB.Connection Dim rs As ADODB.Recordset Dim logConn As ADODB.Connection ' 主连接：用于业务查询 Set conn = New ADODB.Connection conn.ConnectionString = "Provider=SQLOLEDB;Data Source=127.0.0.1;Initial Catalog=TestDB;User ID=test;Password=test123;" conn.Open ' 查数据 Set rs = New ADODB.Recordset rs.Open "SELECT FID, FName, FSalary FROM t_Employee WHERE FSalary > 3000", conn, adOpenStatic, adLockReadOnly Do While Not rs.EOF Debug.Print rs.Fields("FName").Value & " - " & rs.Fields("FSalary").Value rs.MoveNext Loop rs.Close ' 改数据 conn.Execute "UPDATE t_Employee SET FSalary = FSalary + 100 WHERE FID = 1" ' 写日志到另一个库 Set logConn = New ADODB.Connection logConn.ConnectionString = "Provider=SQLOLEDB;Data Source=127.0.0.1;Initial Catalog=LogDB;User ID=test;Password=test123;" logConn.Open logConn.Execute "INSERT INTO t_OperLog (FTime, FDesc) VALUES (GETDATE(), 'salary update')" conn.Close logConn.Close End Sub这个示例串起了四个关键动作。注意查询用的是 Recordset 加游标控制，能随机访问；更新用的 conn.Execute 直连执行，速度快、没有任何结果集返回；日志库是独立连接，避免日志表被锁时影响主业务。三个对象各自独立 Open 和 Close，别写在一个连接里，这是老系统常见的性能瓶颈来源。
连接串里 Provider=SQLOLEDB 是 SQL Server 的 OLE DB 提供程序。如果你连的是 Access，用 Microsoft.Jet.OLEDB.4.0 或 ACE 版本；连 MySQL 则用 MySQL 官方的 ODBC 驱动，再通过 MSDASQL 桥接——后者链路长，配置麻烦，能直连就用直连。连接串里的 Data Source 是实例名，带命名实例要写成 Server\InstanceName 或者用逗号加端口，比如 localhost,1433。Initial Catalog 对应数据库名，注意别和 Windows 的 DNS 或 ODBC 数据源混了，这个串可以直接用，不需要提前建 DSN。
3.3 打开之前的身份认证选择：Windows 认证与 SQL 认证
连接串里写用户名密码是 SQL Server 认证，要求数据库的登录名有权限；不写用户名密码、只写 Integrated Security=SSPI，就是 Windows 认证，用的是当前进程的 Windows 身份。两种方式各有利弊。SQL 认证适合服务程序在后台运行、无人值守的场景，密码存在配置里；Windows 认证更安全，因为不落明文，但要求运行进程的账户有数据库权限。
在代码里硬编码用户名密码是开发期最快的办法，但上线前一定要把连接串挪到配置文件或注册表，否则换一个库密码要重新编译整个程序。这个点虽然简答，但很多从源码包里直接抄连接串的人都会栽在环境差异上——本地用 SQL 认证连得通，上了服务器发现密码策略不同，连接直接被拒。建议把配置拆分：数据库地址、实例名、库名、认证方式各占一个配置项，程序启动时再拼成连接串。这样测试环境、预发布环境、生产环境就只是配置不同，代码完全不变。
3.4 验证封装的健壮性：断网、错表、错类型三种测试
代码跑通一遍只代表主路径正常。一个封装类是否可靠，还得看异常路径的处理。按我的习惯，拿到库的第一轮测试永远是这三件事：第一，把 Data Source 改成一个不存在的 IP，确认连接超时是可控的，而不是卡死三分钟；第二，把表名 t_Employee 改成 t_Employeex，看报错信息能不能明确提示是表不存在还是权限不足；第三，类型不匹配，比如 FSalary 存一个字母进去，确认类型转换错误没有泄漏到界面层。
On Error GoTo ErrHandler conn.Open Exit Sub ErrHandler: Err.Raise vbObjectError + 1001, "AdoHelper", "数据库连接失败，请检查网络或账号权限。原始错误：" & Err.Description这段代码把底层错误包装成业务信息，原始错误保留在后半段。这样做的好处是去掉了 COM 返回的一长串技术编号，最终用户能看懂；而出问题的原始描述还留在 Err.Description 里，开发自身排查成本也不会增加。好的源码包里边全是这种细节，你读的时候重点看它的错误处理，而不只是看它连库连得有多顺。
4. ADO开发避坑：连接串、游标、释放与乱码的六个血泪现场
4.1 连接串用错 Provider，报"未找到提供程序"
现象：运行代码时弹出错误"未找到提供程序。可能未正确安装"，检查引用也没问题。原因通常是连接串里的 Provider 字符串拼错，或者目标平台缺对应驱动。比如 Access 的 Jet 驱动在老系统上要装 Office 组件才有，Windows 64 位系统上再跑 32 位 Jet 也会冲突。
解决：先查本机驱动，在注册表 HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ 下搜 OLEDB Provider 列表，确认实际装了什么。Access 文件优先用 Microsoft.ACE.OLEDB.12.0，没有就用 4.0，再没有就装 Access 数据库引擎。另外注意 .accdb 文件必须配 ACE 驱动，Jet 4.0 只能读 .mdb。连接前先单独写一小段代码验证 Provider 是否可建立连接，别把 Provider 问题和代码逻辑混一起排查。
4.2 记录集打开成功，一 UPDATE 就报"操作不被允许"
现象：rs.Open 正常返回数据，但调用 rs.Update 时提示"当前记录集不支持更新"。原因有两个高频可能：一是游标类型用成了 adOpenForwardOnly，这种游标只支持向前移动，天然禁止原地更新；二是游标位置用了 adUseServer，且锁类型设成 adLockReadOnly，读锁自然不能改数据。
解决：先明确你需要什么能力。如果只想遍历并逐条改，用 adOpenStatic 加 adLockOptimistic；如果想真正并发控制，用 adOpenKeyset 加 adLockPessimistic。一个常用的取数加改数的组合是：CusorLocation 设 adUseClient，CursorType 设 adOpenStatic，LockType 设 adLockBatchOptimistic，这样改了数据后用一个 rs.UpdateBatch 批量提交，性能好且断开连接后仍能工作。
4.3 程序多开几次，数据库连接数蹭蹭涨
现象：进程管理器看到数据库连接几十个，程序关掉后连接还挂着，最终把数据库的连接池耗尽。原因：代码里只调用了 Close，没有把对象引用置空。在 COM 对象里 Close 只是归还连接，而对象本身仍在内存中，其内部引用计数如果还被变量拽着，连接就不会真正释放。
解决：严格遵循 Set conn = Nothing，而且必须在 Close 之后执行。最好写在 Finally 或错误处理的出口分支里，保证任何路径都走释放流程。封装库把这一步包进析构函数是常见做法，类销毁时自动 Close。调试时在 SQL 端执行 sp_who2 或查 sys.dm_exec_connections 能直接看到残留连接，定位到具体是哪个对象未清理。
4.4 从数据库读出中文显示成乱码
现象：SQL Server 里中文正常，代码读出来显示"???"，或者反过来界面正常但写进库变成乱码。原因：客户端与数据库之间的字符集不匹配。SQL Server 中 varchar 类型受数据库排序规则影响，而 nvarchar 类型是 Unicode 编码。如果表字段是 varchar，而客户端代码用的字符集是 GBK 或 UTF-8 的混杂状态，读写就会发生转码错位。
解决：字段设计上尽量用 nvarchar，代码这边打开 Recordset 前设置连接属性，确保 ODBC/OLE DB 的编码一致。对于已用 varchar 的存量表，连接串追加 CharacterSet=UTF-8 参数可以缓解，但根本解决办法还是统一字段类型与客户端代码页。排查时把读出来的字符串的字节序列打印出来看编码，再跟预期比对，别在乱码界面上一头雾水地乱试。
4.5 UPDATE 执行没报错，表里数据却毫无变化
现象：conn.Execute 执行 UPDATE 返回成功，但查 SELECT 发现行没变。原因大多数是 WHERE 条件把行集限得太窄，或者目标行的类型隐式转换失败后静默忽略。比如拿字符串"123abc"去更新整型字段，数据库按匹配规则判断为空，生成零行更新却不报错。
解决：Execute 之前先跑同样的 SELECT 确认影响行数。还有一个隐蔽原因是事务未提交，如果连接开了事务而代码里只做了 BeginTrans 却没有 CommitTrans，程序退出时事务回滚，改动全部消失。这种情况最坑，因为单步调试跟预期一致，一断就全没了。养成习惯：执行的 SQL 返回值通过 RecordsAffected 参数接住，判断影响行数是否与预期一致。
4.6 记录集 MoveNext 循环卡死，CPU 飙升
现象：Do While Not rs.EOF 循环内对同一个数据表执行了增删操作，越循环越慢，最后像卡住。原因：循环体内使用同一个连接再次执行对同一张表的改动，导致当时的游标定位失效，ADO 不断重试定位下一行。这是老程序员嘴里的"游标漂移"，加删除操作会打断服务端游标的行进顺序，客户端还在按旧的 bookmark 往下跳。
解决：循环遍历中如果需要改本表数据，先把主键收集到一个数组里，循环结束再统一 UPDATE；或者改用断开式记录集，加载完后立刻关闭连接，将数据快照放内存里遍历。上述代码中最大的教训是不要把写操作和遍历操作混在同一个 Recordset 生命周期里，加了写操作就要考虑它对游标的影响。
5. 把参数化查询和批处理刻进习惯里
参数化查询不是加分项，是底线操作。用拼接字符串的方式构造 SQL，比如 "SELECT * FROM t_Order WHERE FNo = '" & txtNo.Text & "'"，一旦文本框里输入的是 "1' OR '1'='1"，整个查询条件就被改写，轻则把全表数据捞出来，重则删库清表。我刚接手项目时，常在既有代码里看到整段字符串拼接，看得心里发毛。改成参数后，输入内容只是值，不再参与 SQL 结构拼装，这一类漏洞就算堵死了一半。
Dim cmd As ADODB.Command Set cmd = New ADODB.Command Set cmd.ActiveConnection = conn cmd.CommandText = "SELECT * FROM t_Order WHERE FNo = ? AND FStatus = ?" cmd.CommandType = adCmdText cmd.Parameters.Append cmd.CreateParameter("@no", adVarWChar, adParamInput, 32, txtNo.Text) cmd.Parameters.Append cmd.CreateParameter("@status", adInteger, adParamInput, , 3) Set rs = cmd.Execute这段代码与前文用过的内联参数查询唯一区别是多了一个覆盖了多参数的例子。写参数时有几个细节值得较真：adVarWChar 这类可变长字符类型必须给长度，不然有时会因默认长度不足而截断数据；数值类型长度不用填，给个默认空即可。在 VBA 里逐个 Append 参数看着繁琐，但你可以封装一个 SetParam 函数，让调用方只需传名字、类型、值，减少重复代码。
批处理则把性能上限拔高一截。传统的逐条 INSERT 一千条数据可能要十几秒，改用 Recordset 批量提交的方式大概能压到 2 秒内。Core 思路是把 UPDATE 攒在客户端记录集里，一把梭调 UpdateBatch：
Set rs = New ADODB.Recordset rs.CursorLocation = adUseClient rs.Open "SELECT FID, FSalary FROM t_Employee WHERE FDeptID = 8", conn, adOpenStatic, adLockBatchOptimistic Do While Not rs.EOF rs.Fields("FSalary") = rs.Fields("FSalary") * 1.1 rs.MoveNext Loop rs.UpdateBatch这段代码把整个部门的薪水上调 10%，但只发起了一次批量更新，大幅降低网络往返次数。预算有限的老系统数据库，往往就是靠这种改动把性能拉回来的。代价是批量模式需要排他锁或乐观锁配合，如果多人同时改同一批数据，UpdateBatch 的冲突回滚会让你手忙脚乱，务必先确认业务上允许你占用这批数据的更新权。
还有一件事我建议贯穿在所有 ADO 使用里：把 CommandTimeout 调显式化。默认 30 秒对报表系统的深夜批处理不够，经常跑到 20 分钟被断。我一般会在封装库的初始化处统一设置为 300 秒，单条大查询单独覆盖更大值。后端数据库里跑大查询时同步调整 SQL 命令的超时参数，两边对齐才不会出现代码等不到结果先自杀的诡异局面。
这些习惯不复杂，但它们决定了一份 ADO 源码包在你手里是趁手的工具，还是埋雷的负担。我自己的教训是：每次拿到新的源码包，第一件事永远是加充足日志，把连接串、影响行数、耗时全部打印出来。很多难缠问题，事后看都是缺日志导致瞎猜。希望这些经验帮到你，少走我走过的弯路。
本文还有配套的精品资源，点击获取
