简介在VC开发中ADOActiveX Data Objects是常用的数据访问接口而Command对象则是执行SQL语句、调用存储过程的核心。这份面向数据库编程初学者的实战Demo围绕_CommandPtr智能指针展示完整调用链路创建Command实例、绑定ActiveConnection、用CommandText与CommandType指定命令类型如adCmdText、adCmdStoredProc、创建Parameter并设置数据类型与输入方向、通过Execute取得Recordset或影响行数并包含try-catch异常处理写法。资源为Visual Studio解决方案TestAdo共11个文件压缩包仅8KB文件以3个.cpp源文件、3个.h头文件、1个txt说明及.vcxproj/.sln/.filters/.user工程配置为主结构精简可直接打开编译、对照源码学习。这份示例能让读者在真实VC工程中看到对象创建、属性设置、存储过程调用与带参查询的落地方式避免连接与参数绑定的常见错误快速建立ADO Command对象使用框架适用于日常数据查询、更新及存储过程调用等场景。已有524人学习下载适合希望快速上手VC数据库访问、需要轻量参考工程的开发人员。1. 当 Connection.Execute 不够用的时候就该轮到 Command 对象出手了很多人写 ADO 代码习惯用一个 Connection 对象走天下conn.Execute SELECT ...方便顺手查个表、更新几行数据完全够用。直到某天要调用一个带输入参数和输出参数的存储过程或者要防止 SQL 注入、按条件动态拼查询时才发现Connection.Execute这条捷径走不通了——SQL 串里的参数怎么传存储过程的返回值怎么接执行完的结果集被自动关闭了怎么办这时候你需要的才是 ADO 真正的主角之一Command 对象。这篇笔记围绕「ADO 实例里 Command 对象的使用」展开我会把 Command 的职责边界、创建方式、参数化查询、存储过程调用全部拆开讲附带可直接抄走的 VBA 代码和几段我实际踩过的坑。适合正在维护老系统、用 Excel/VBA 做数据工具、或者刚接手 ASP/桌面程序里 ADO 代码的开发者——搞清楚 Command 对象你就能从只会执行 SQL 字符串进阶到能安全地操作参数、拿到输出值和返回值这部分能力是 Connection 单对象给不了你的。2. Command 对象在 ADO 中的地位为什么存储过程和参数化离开它就不顺2.1 三大核心对象的职责边界Connection 管连接、Recordset 管数据、Command 管命令ADO 里的对象很多但日常打交道的核心只有三个Connection、Command、Recordset。刚上手的人最容易犯的错误是只认 Connection 和 Recordset把 Command 当成一个可有可无的中间层。真实情况恰恰相反在你需要执行带参数的命令时Command 是唯一能完整表达这条命令长什么样的对象。三个对象的分工可以这样理解Connection 是管道负责跟数据库建立会话、维护连接状态、管理事务Recordset 是结果容器负责把查询出来的数据装进内存支持游标滚动和增删改Command 则是命令本身——它描述我要执行一段什么样的 SQL 或存储过程参数是什么期望拿到什么。如果你直接拿 Connection.Execute 执行 SQL本质上是把命令压缩成了一个字符串丢给管道命令本身的元数据参数类型、方向、长度全部丢失了。一个很直观的对比场景你要向用户表插入一条数据密码字段是加密后的哈希串。用Connection.Execute写你得在 SQL 字符串里自己拼引号、处理特殊字符还得担心注入用 Command 写参数是单独绑定进去的值本身是数据而不是 SQL 文本的一部分。这个差异决定了你的代码是把数据拼进字符串还是把数据交给命令后者才是数据库访问该有的方式。Command 对象另一个容易被忽略的职责是承载命令的全部上下文。它除了 CommandText命令文本和 CommandType命令类型之外还带一个 Parameters 集合这个集合专门存放参数的定义——每个参数的名字、数据类型、方向输入还是输出、长度、实际值。Recordset 只管结果Connection 只管连接唯独 Command 把这些信息完整地串起来。所以只要你的命令里带参数或者要调用存储过程并拿返回值Command 对象就不是可选优化而是唯一正解。2.2 什么时候必须用 Command三种典型场景与选型判断不是所有数据库操作都需要 Command。我的习惯是先做判断简单的、无参数的单条 SQL比如查一个配置表、更新一个状态位Connection.Execute 够用没必要多套一层但下面三种场景我都会直接上 Command省得事后返工。第一种是参数化查询。用户输入的值要拼进 SQL 时登录校验、按条件筛选、模糊搜索绝对不能直接字符串拼接而是用?占位符加 Parameters 集合传值。这既是防注入的正确姿势也避免了字符串里引号嵌套的转义噩梦。尤其处理中文、单引号、百分号这些字符时参数化能让你少写一堆 Replace 逻辑。第二种是调用存储过程。存储过程往往带输入参数、输出参数、返回值还可能返回多个结果集。用 Connection.Execute 执行EXEC 存储过程 参数1, 参数2虽然能跑但输出参数和返回值完全拿不到——它们需要 Command 的 Parameters 集合专门声明方向才能接收。再进一步如果存储过程内部有临时表、有依赖执行顺序的局部变量Connection.Execute 的直通方式很容易在 Provider 层面出奇怪的错误而 Command 配合adCmdStoredProc类型会更稳。第三种是命令需要复用且参数会变。比如循环里要批量插入一万行数据每次只是参数值不同命令结构完全相同。用 Command 对象可以创建一次命令循环里只改 Parameters 的值省去每次重新解析 SQL 的开销。这个优化在 Excel VBA 里体感尤其明显——慢了能差出几分钟。判断标准可以再简化一点只要命令文本里需要出现外部传入的值或者需要接收除结果集以外的东西输出参数、返回值就建立 Command。如果只是固定 SQL、无参数、不关心返回值Connection.Execute 才合适。2.3 两个常被混淆的执行入口Connection.Execute 与 Command.Execute 的差异很多新手代码里会出现conn.Execute cmd.CommandText这种写法——Connection 和 Command 都存在但执行时用的是 Connection 的 Execute。这没有语法错误但在带参数的场景下会翻车因为 Connection.Execute 只能接收完整拼好的 SQL 文本它根本不知道 Command 的 Parameters 集合里有什么。等于你精心绑定了参数执行时却把这些参数丢掉只把 CommandText 这条字符串发给了数据库结果自然是参数 xxx 未声明之类的报错。正确做法是始终调用cmd.Execute。Command.Execute 的执行路径是这样的读 CommandType 决定如何解析 CommandText读取 Parameters 集合把参数值传给数据库执行引擎执行完成后把结果集封装成 Recordset 返回如果命令返回结果集的话。它把整个命令上下文完整地交给了数据库而不是只交一段字符串。另一个差异在返回值上。Connection.Execute 如果执行的是 SELECT返回的 Recordset 默认是前向只读游标而且很多新手发现执行 UPDATE 语句后 Recordset 是 Nothing——这是正常行为因为更新类语句没有结果集但如果你想拿到诸如受影响的行数Connection.Execute 的返回值可以拿到只是很多人不知道去接。Command.Execute 则不同它有 options 参数可以控制执行行为和结果集获取方式结合adExecuteNoRecords等选项能让更新类命令的执行意图更明确也避免 Provider 无谓地准备一个空 Recordset。这两个入口搞混是排查参数没生效明明写了 Execute 却没执行这类问题时的头号嫌疑。记住一条铁律绑定在 Command 上的参数只能由 Command 自己去执行想用 Connection 执行你就别用 Command 绑定参数二选一别混搭。3. 最小可运行实例用 ADO Command 跑通第一句 SQL3.1 准备工作引用 ADO 库与连接字符串的写法实操之前先说环境。我下面的代码统一用 VBA 演示——Excel 或 Access 的 VBA 编辑器里都能跑这也是 ADO Command 对象最经典的落地环境。如果你在用 C# 或 VB.NET底层引用 COM 库也是同一套 ADODB 对象模型类名、枚举名基本一致只有语法外壳不同理解原理后平移过去不难。第一步是添加 ADO 库引用。在 VBA 编辑器里按 AltF11菜单栏选择工具 - 引用勾选 Microsoft ActiveX Data Objects 2.8 Library不同系统版本号可能有差异选可用的最高版本即可。如果你不想勾引用也可以用CreateObject(ADODB.Connection)这种后期绑定写法代码照样能跑只是没有智能提示。我推荐前期调试用前期绑定勾引用有代码提示能少打错好多枚举名项目交付时再考虑要不要改后期绑定避免目标机器上没有对应版本的 ADO 库文件。连接字符串这边最常见的是 SQL Server 的 SQLOLEDB Provider。我在工程里惯用的写法是Dim conn As Object Set conn CreateObject(ADODB.Connection) conn.ConnectionString ProviderSQLOLEDB;Data Source服务器名;Initial Catalog数据库名;User ID用户名;Password密码 conn.Open这里的Provider指定数据库驱动SQL Server 用 SQLOLEDB老机器或 SQLNCLIAccess 数据库则用 Microsoft.ACE.OLEDB.12.0。Data Source是数据库服务器地址本地开发可能就是127.0.0.1或者一个具名实例服务器名\实例名。Initial Catalog是库名。生产环境我不建议把密码明文写死在代码里但 VBA 工具内部使用场景很多人图省事直接写这属于风险取舍你心里有数就行。3.2 创建 Command、绑定连接、执行更新语句的最小代码连接打开之后创建 Command 并执行是四步创建对象、绑定连接、设置命令文本、执行。以一条库存扣减语句为例完整代码如下 连接已经打开conn 是 ADODB.Connection 对象 Dim cmd As Object Set cmd CreateObject(ADODB.Command) 把命令绑定到已打开的连接上 Set cmd.ActiveConnection conn 告诉命令这是一段 SQL 文本不是存储过程名 cmd.CommandType adCmdText 设置要执行的 SQL 语句 cmd.CommandText UPDATE 库存表 SET 数量 数量 - 1 WHERE 商品ID P001 执行命令更新类语句不返回结果集这里不用接返回值 cmd.Execute这段代码的逻辑线是先建一个独立的 Command 对象把它跟已打开的连接关联起来——注意是Set cmd.ActiveConnection conn传的是 Connection 对象本身而不是连接字符串。这一步决定了命令走哪条连接执行。cmd.CommandType adCmdText是告诉 ADO 去解析 CommandText 里的文本而不是去数据库里找一个名叫UPDATE 库存表...的对象。最后cmd.Execute真正把命令发出去。这里要特别说明CommandType的重要性如果漏掉这行ADO 默认按adCmdUnknown处理让 Provider 自己猜 CommandText 到底是什么。Provider 猜 SQL 文本通常没问题但一旦遇到以某些特殊字符开头的文本或者文本里包含注释、分号、GO 批处理分隔符猜测逻辑就可能出错执行直接抛异常。我的习惯是显式声明adCmdText一行代码消除一整类不确定性。另外注意一点如果命令是 SELECT 查询cmd.Execute会返回一个 Recordset 对象你需要用Set rs cmd.Execute接住它。如果执行的是 UPDATE、DELETE、INSERT 这类不返回行的命令Execute 返回 Nothing属于正常现象不用觉得代码有问题。3.3 参数化查询怎么写问号占位与 CreateParameter 的对应关系参数化是 Command 对象最值得学的部分。在 ADO 里SQL 文本中的参数占位符统一用问号?而不是 SQL Server 里的参数名。这个差异坑了很多人——你写WHERE 客户名称 custName然后追加一个名为 custName 的参数执行时却报必须声明标量变量。原因就是 ADO 在把命令交给 Provider 之前会把 Parameters 集合里的参数按顺序绑定到?占位符上文本里没有?参数就成了无主之物。正确的写法是把 SQL 里的参数位置全部改成?然后用cmd.CreateParameter逐一创建参数并 Append 进集合。看这段代码Dim cmd As Object Set cmd CreateObject(ADODB.Command) Set cmd.ActiveConnection conn cmd.CommandType adCmdText 占位符用问号对应后面的参数按顺序绑定 cmd.CommandText SELECT * FROM 订单 WHERE 客户名称 ? AND 金额 ? 创建第一个参数客户名称类型为宽字符方向为输入长度50值为“某客户” Dim p1 As Object Set p1 cmd.CreateParameter(客户名, adVarWChar, adParamInput, 50, 某客户) cmd.Parameters.Append p1 创建第二个参数最小金额类型为货币输入方向值为100 Dim p2 As Object Set p2 cmd.CreateParameter(最小金额, adCurrency, adParamInput, , 100) cmd.Parameters.Append p2 执行并取回结果集 Dim rs As Object Set rs cmd.ExecuteCreateParameter 的五个参数是固定的第一是参数名随意起主要用于在 Parameters 集合里按名字索引第二是 ADO 数据类型枚举第三是参数方向adParamInput表示输入参数第四是长度字符串类型一般要跟字段定义一致数字、日期这类固定长度类型可以不传第五是参数值。执行时ADO 按 Append 的顺序将参数绑定到 SQL 文本里从左到右的?上顺序绝对不能乱。参数化的好处不仅是防注入——绑定的值由 Provider 负责转义和传输不存在单引号把 SQL 截断的问题。处理包含%、_的用户输入做模糊查询时也不用自己写转义逻辑参数值原样传输LIKE语义由数据库端处理。另外中文乱码问题在参数化之后也会缓解不少只要 Type 用adVarWChar宽字符而不是adVarChar单字节字符中文就能原样入库。4. 调用带参数的存储过程Command 对象的完整用法4.1 存储过程调用前的三个前置设置CommandType、CommandText、参数容器存储过程是 Command 对象的主场。调用存储过程和执行 SQL 文本最大的区别在于ADO 需要明确知道你要调用的不是一个文本而是一个数据库对象。这里有两个设置必须同时做对cmd.CommandType adCmdStoredProc以及cmd.CommandText 存储过程名。adCmdStoredProc这个枚举值是在告诉 ADOCommandText 里的内容是数据库里一个已存在的存储过程名ADO 会按存储过程的协议去调用而不是把它当 SQL 文本解析。这两者最直接的区别体现在参数处理上当 CommandType 是 adCmdStoredProc 时ADO 对参数的绑定顺序参考存储过程定义本身的参数列表当你调用带参数的存储过程但参数追加顺序不对时老版本的 Provider 甚至不报错而是按位置匹配把值传给了错误的参数数据就在你眼皮底下写错了。第三个前置设置是参数容器。调用存储过程之前要么手动 Append 参数推荐可控性好要么调用cmd.Parameters.Refresh让 ADO 去数据库读取参数元数据省事但会多一次往返而且某些 Provider 对 Refresh 支持不完整。我一般手动 Append虽然代码多几行但每个参数的方向、类型都在自己掌控里不会因为 Provider 抽风把输出参数误判成输入参数。4.2 输入参数、输出参数、返回值三者的追加顺序与读取时机下面这段代码演示的是最完整的存储过程调用——同时接收输入、输出和返回值。假设数据库里有这么一个存储过程传入订单ID计算订单总金额后返回给输出参数同时用返回值表示处理状态。Dim cmd As Object Set cmd CreateObject(ADODB.Command) Set cmd.ActiveConnection conn cmd.CommandType adCmdStoredProc cmd.CommandText usp_计算订单汇总 第一个参数返回值方向是 adParamReturnValue cmd.Parameters.Append cmd.CreateParameter(RETURN_VALUE, adInteger, adParamReturnValue, , 0) 第二个参数输入参数订单ID cmd.Parameters.Append cmd.CreateParameter(订单ID, adInteger, adParamInput, , 1024) 第三个参数输出参数总金额注意货币类型和长度设置 cmd.Parameters.Append cmd.CreateParameter(总金额, adCurrency, adParamOutput, , 0) 执行存储过程 cmd.Execute 执行完成后必须先读输出参数和返回值再处理可能的结果集 Dim total As Currency total cmd.Parameters(总金额).Value Dim ret As Integer ret cmd.Parameters(RETURN_VALUE).Value这里最关键的规则是追加顺序有返回值时必须先追加adParamReturnValue方向的参数再追加输入参数、输出参数。很多 Provider 是按参数在集合里的位置顺序向存储过程传值的你把返回值放在最后数据库可能把第一个输入参数当成返回值的位置去处理轻则值取错重则直接报参数对象定义不正确。第二规则是读取时机Execute 返回后立刻读取输出参数和返回值再去消费 Recordset。如果命令本身还返回了结果集而你先把 Recordset 遍历完再去读参数在某些 Provider 下会拿到空值——因为结果集没消费完之前后续参数值可能还没被填充或者连接资源被占住导致取值动作失效。我的习惯是如果有返回值/输出参数Execute 那行后面紧跟的就是参数读取代码哪怕结果集还没读也用变量先存下来再说。第三规则是输出参数的长度问题。CreateParameter(总金额, adCurrency, adParamOutput, , 0)里长度那个参数我传了 0。实际上字符串类型的输出参数长度不能省略——比如输出参数是 VARCHAR(50)CreateParameter 的第四参数必须给 50否则有些 Provider 会按默认长度创建写回的字符串被截断或者更糟执行时报列宽太小无法写入数据。数值、货币、日期这类固定类型可以不填字符串必须有。这也是排查输出参数空值时最容易被忽略的一条。4.3 拿不到输出参数时的自查清单输出参数拿不到值是 Command 对象使用里最高频的翻车现场。我的排查顺序是固定的按下面四条逐项查第一检查追加顺序。返回值必须在最前面然后输入参数、输出参数顺序和执行存储过程时的参数位置保持一致。如果你看到输出参数里读到的是 0 或者默认值多半就是顺序错位值被传给了别的参数。第二检查读取时机。Execute 之后有没有先读参数再碰 Recordset如果你先遍历了结果集甚至先关闭了 Recordset再回头取参数值有些 Provider 返回的就不是期望值了。记住先读参数后消费结果集。第三检查字符串输出参数的长度。输出参数如果是 VARCHAR(100)CreateParameter 第四参就得写 100。不写长度Provider 可能默认建一个长度 0 或极小的参数容器写入时数据被截断你拿到的是看起来存在但内容不对的值。第四检查参数的名称匹配。虽然很多 Provider 按位置绑定但有一部分场景下 ADO 会按名称去匹配存储过程的参数。你的 CreateParameter 第一参名称和存储过程定义里的参数名不一致轻则找不到参数重则创建了一个额外参数导致执行报参数数量不匹配。这个坑在 SQLOLEDB 和 SQLNCLI 上面表现不一致我的建议是创建参数时名字严格照抄存储过程定义里的参数名不要自己另起名。5. Command 对象使用中的常见问题与排查五次踩坑记录5.1 命令类型设错把 SQL 当存储过程执行现象CommandText 里明明写的是SELECT * FROM 订单执行却报错提示找不到对象或者无效的 SQL 语句有时候甚至执行成功但返回一堆看不懂的结果。原因CommandType 被设成了adCmdStoredProc或者默认的 adCmdUnknown 导致 Provider 猜错。ADO 收到 adCmdStoredProc 后会把 CommandText 当成存储过程名去匹配数据库里的对象SELECT * FROM 订单自然匹配不到。解决确定你的命令是普通 SQL 文本就显式赋值adCmdText是存储过程就adCmdStoredProc不要依赖 Provider 去猜。如果代码里两种命令混用建议每次设置完 CommandText 后紧跟着设置 CommandType养成文本和类型成对出现的编码习惯。5.2 参数顺序不对输出参数读到 0 的根因现象存储过程调用成功没有报错但输出参数读回来永远是 0 或者默认值如果存储过程里有多个输入参数还会出现数据写错列、查询结果不符合预期的情况。原因老版本 SQLOLEDB Provider 按位置匹配参数而不是按名称。你的 Parameters 集合里追加参数的顺序和存储过程定义的参数顺序不一致时值被传给了错误的位置。最典型的是返回值没放在第一位把 ADO 的参数顺序整体往后挤了一位。解决手动 Append 参数时严格按返回值在前然后输入参数、输出参数的顺序追加有多个输入参数时对照存储过程定义逐个核对顺序。如果存储过程参数较多写一个注释把存储过程的签名抄在代码上方逐行对齐。这个习惯帮我少踩了好多次坑。5.3 中文字符乱码Type 选错导致的隐性故障现象参数值是中文库里存进去变成???或者查询时中文条件查不到数据英文数值全部正常。原因CreateParameter 的类型用成了adVarChar单字节字符类型而 SQL Server 的 NVARCHAR、VARCHAR 存储中文时建议走 Unicode 类型。adVarChar 只适合纯 ASCII 字符中文字符传过去被截断或转换成了问号。解决凡是可能包含中文的字符串参数统一用adVarWChar作为类型。注意不是字符串就用 adVarChar——在 ADO 的世界里Unicode 优先。另外输出参数是字符串时也别忘这个规则否则从库里读回来的中文字段照样乱码。这个坑的特点是平时不炸一遇到中文业务数据就集体出问题而且很难凭报错信息定位。5.4 ActiveConnection 赋值方式不一致引发的对象已关闭现象Command 对象创建好后执行cmd.Execute报对象已关闭或连接未打开但你明明在上一行才打开过连接。原因给cmd.ActiveConnection赋值时写成了cmd.ActiveConnection conn.ConnectionString而不是Set cmd.ActiveConnection conn。前者是把连接字符串字符串塞给 CommandCommand 会尝试用这个字符串自己建一条新连接但这条连接没有任何人调用 Open所以执行时它处于关闭状态。解决统一用Set关键字把 Connection 对象赋给 ActiveConnection。如果 Command 借用连接的方式写对了还是报对象已关闭再检查连接是否真的处于打开状态——尤其是用 CreateObject 创建的后期绑定连接Open 的调用很容易被漏掉。顺带一提Command 是可以单独持有一条不对外暴露的连接的不赋值 ActiveConnection而是给cmd.ActiveConnection赋连接字符串Command 会自己打开和关闭连接适合一次性执行的场景但日常调试不推荐。5.5 循环执行时参数残留复用 Command 必须清空 Parameters现象循环里反复执行同一条命令第一次结果正常第二次开始报参数数量不正确或参数 xxx 已经存在有时还出现值张冠李戴。原因Command 对象复用时Parameters 集合里的参数是累积的。第一次循环 Append 了三个参数第二次又 Append 三个集合里就有六个参数或者你直接改已有参数的 Value但某些情况下参数被标记为已使用而状态未重置。解决复用 Command 之前用cmd.Parameters.Delete逐个删除或者直接调用cmd.Parameters.Refresh重建集合。更彻底的做法是循环内对参数值做整体赋值——cmd.Parameters(参数名).Value 新值——而不是重新 Append。我的习惯是结构固定就只改 Value结构可能变化就先清空整个 Parameters 集合再重建。这两条路径选一条走别混着来。这个坑在批量导入、批量更新的场景里几乎是必踩的代码一旦跑起来报错先怀疑参数残留比先怀疑 SQL 语句靠谱。6. 让 Command 对象更顺手复用技巧与一个通用封装把 Command 对象用熟之后你会发现它最大的价值不只是能调存储过程而是命令结构可以定义一次、反复执行。我在做某个模拟项目X的数据迁移工具时要往库里的订单表插入十几万行历史数据最开始用字符串拼接 INSERT跑一次要二十多分钟后来改成 Command 对象复用创建一次命令循环里只改 Parameters 的 Value耗时直接降到四分钟以内。差距在哪字符串拼接每次都要重新解析 SQL、重新构造语句而 Command 的参数化方案把 SQL 解析的活留给了 Provider 做一次后续只传数据。一个值得养成的习惯是把 Command 的创建和执行封装成一个通用函数参数用数组传进去。以 VBA 为例类似这样Function RunCommand(ByVal conn As Object, ByVal sql As String, ByVal params As Variant) As Object Dim cmd As Object Set cmd CreateObject(ADODB.Command) Set cmd.ActiveConnection conn cmd.CommandType adCmdText cmd.CommandText sql params 是二维数组每行依次为参数名、类型、方向、长度、值 Dim i As Integer For i LBound(params, 1) To UBound(params, 1) cmd.Parameters.Append cmd.CreateParameter( _ params(i, 0), params(i, 1), params(i, 2), params(i, 3), params(i, 4)) Next i Set RunCommand cmd.Execute End Function这样封装之后业务代码就变成一行行的参数表传递再也不用手写五个 CreateParameter 的样板代码。封装里我建议额外加一个步骤执行前清空 Parameters 集合保证同一个 Command 对象不会因为上一轮残留参数而出错。这比每次重新创建 Command 更高效也比不清理直接复用更稳。最后说我个人的习惯每写完一段 ADO 代码我习惯在注释里写明 Provider 类型和 CommandType因为这两样决定了参数的行为模式换台机器、换个数据库驱动这个注释能帮下一任维护的同事省下半天排查时间。这个习惯来自一次真实的血泪教训——线上工具在本地用 SQLOLEDB 跑得好好的换到装了新驱动的服务器上就报参数错误查了两小时才发现是 Provider 行为差异。Command 对象本身不难难的是知道它背后依赖哪些环境变量。把环境信息留在代码里也算给自己留一份后悔药。希望这篇能帮到正在跟 ADO 打交道的你。本文还有配套的精品资源点击获取