简介面向商业开发场景的 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到RecordsetADO的核心对象与封装思路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 ProviderSQLOLEDB;Data Sourcelocalhost;Initial CatalogMesDB;User IDsa;Password123456 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 ProviderSQLOLEDB;Data Source127.0.0.1;Initial CatalogTestDB;User IDtest;Passwordtest123; 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 ProviderSQLOLEDB;Data Source127.0.0.1;Initial CatalogLogDB;User IDtest;Passwordtest123; 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别写在一个连接里这是老系统常见的性能瓶颈来源。连接串里 ProviderSQLOLEDB 是 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 SecuritySSPI就是 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 设 adUseClientCursorType 设 adOpenStaticLockType 设 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 的存量表连接串追加 CharacterSetUTF-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 11整个查询条件就被改写轻则把全表数据捞出来重则删库清表。我刚接手项目时常在既有代码里看到整段字符串拼接看得心里发毛。改成参数后输入内容只是值不再参与 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 攒在客户端记录集里一把梭调 UpdateBatchSet 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 源码包在你手里是趁手的工具还是埋雷的负担。我自己的教训是每次拿到新的源码包第一件事永远是加充足日志把连接串、影响行数、耗时全部打印出来。很多难缠问题事后看都是缺日志导致瞎猜。希望这些经验帮到你少走我走过的弯路。本文还有配套的精品资源点击获取 
长河君 · 2026/10/9 15:21:02 · 阅读 1.2k ADO封装库实战：从Connection到Recordset的核心用法与避坑指南
简介面向商业开发场景的 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到RecordsetADO的核心对象与封装思路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 ProviderSQLOLEDB;Data Sourcelocalhost;Initial CatalogMesDB;User IDsa;Password123456 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 ProviderSQLOLEDB;Data Source127.0.0.1;Initial CatalogTestDB;User IDtest;Passwordtest123; 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 ProviderSQLOLEDB;Data Source127.0.0.1;Initial CatalogLogDB;User IDtest;Passwordtest123; 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别写在一个连接里这是老系统常见的性能瓶颈来源。连接串里 ProviderSQLOLEDB 是 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 SecuritySSPI就是 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 设 adUseClientCursorType 设 adOpenStaticLockType 设 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 的存量表连接串追加 CharacterSetUTF-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 11整个查询条件就被改写轻则把全表数据捞出来重则删库清表。我刚接手项目时常在既有代码里看到整段字符串拼接看得心里发毛。改成参数后输入内容只是值不再参与 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 攒在客户端记录集里一把梭调 UpdateBatchSet 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 源码包在你手里是趁手的工具还是埋雷的负担。我自己的教训是每次拿到新的源码包第一件事永远是加充足日志把连接串、影响行数、耗时全部打印出来。很多难缠问题事后看都是缺日志导致瞎猜。希望这些经验帮到你少走我走过的弯路。本文还有配套的精品资源点击获取