简介对于需要在VC项目中掌握ADO数据访问的开发者而言这是一套可运行的Command对象示例工程。资源围绕ADO核心组件Command演示了从创建_CommandPtr实例、通过Connection的CreateCommand初始化到设置ActiveConnection、CommandText与CommandType再到执行SQL查询和调用存储过程的完整流程。工程还特别实现了Parameter对象与CreateParameter/Append方法用于带参数的查询并辅以try-catch错误处理来应对实际开发中的异常情况。压缩包共11个文件以3个cpp源码和3个头文件为核心另含vcxproj、sln等Visual Studio工程配置整体仅8KB结构精简、便于直接编译运行和对照修改。当前已有523人学习凭借小巧完整的示例代码读者能快速理解Command对象在数据库操作中的实际用法为后续更复杂的数据访问开发奠定基础。1. Ado Command对象为什么SQL最终都用它执行而不是Connection接手过VB6老系统或者维护Access数据库的工程师对ADO里的Command对象一定不陌生。很多人刚开始写数据访问代码时习惯用Connection对象直接Execute一条SQL能跑通就完事直到某天需要做带参数的查询或者一个循环里要执行几千次更新才发现Connection不够用了。ADO里的Command对象就是专门用来承载“一条命令”的它能指定要执行的SQL语句或存储过程能带参数能复用还能控制超时和预编译。这篇笔记围绕Command对象的使用把从最小实例到参数化、存储过程、事务配合和常见报错完整走一遍适合VBA/VB6/ASP老项目维护者以及用Excel或Access做数据工具的开发者。2. 把Command对象跑起来最小实例与四个核心属性2.1 ActiveConnection先有Connection还是先有CommandCommand对象不是独立的执行器它必须挂在一个已经打开的数据库连接上工作。最常见也是最推荐的做法是先创建并打开Connection对象再把Connection对象赋给Command的ActiveConnection属性。下面是一段能直接跑到SQL Server上的最小实例作用是更新一条工资单记录的状态。 VBA/VB6环境需在“工具-引用”里勾选 Microsoft ActiveX Data Objects 2.x Library Dim cn As ADODB.Connection Dim cmd As ADODB.Command Set cn New ADODB.Connection cn.ConnectionString ProviderSQLOLEDB.1;Data Source127.0.0.1;Initial CatalogTestDB;User IDsa;Password123456; cn.Open Set cmd New ADODB.Command Set cmd.ActiveConnection cn 把已打开的连接挂给Command cmd.CommandText UPDATE dbo.Payroll SET Status1 WHERE PayrollID1001 cmd.CommandType adCmdText 告诉ADO这是一段SQL文本 cmd.Execute 不返回结果集所以不要写 Set rs cn.Close Set cmd Nothing Set cn Nothing这里有个容易被忽略的细节Set cmd.ActiveConnection cn用的是赋值对象的方式不是cmd.ActiveConnection cn.ConnectionString。ActiveConnection属性既可以接收一个Connection对象也可以接收一个连接字符串。如果直接给字符串ADO会隐式创建一个连接并在命令执行完后自动释放连接的生命周期不在你手里事务也不好控制。我一般只在写测试脚本时才用字符串方式工程代码里一律先建Connection对象。在执行cmd.Execute之前cn必须已经处于打开状态。有个玄学现象是环境里明明连上了数据库但执行Command时报“对象关闭时不允许操作”检查后才发现Connection对象是在Command赋值之后才Open的。赋值本身不要求连接已打开但Execute那一刻必须开着。2.2 CommandText与CommandType告诉Command要执行什么CommandText是命令的主体可以是SQL语句、表名、存储过程名甚至可以是指向文件的路径。CommandType用来告诉ADO怎么解析CommandText避免它自己去猜。两个属性配对使用是最稳定的写法。CommandType有四个常用枚举值adCmdText表示CommandText是SQL语句adCmdTable表示是表名adCmdStoredProc表示是存储过程名adCmdUnknown让ADO自己推断。不设置CommandType时默认就是adCmdUnknown。很多老代码直接写cmd.CommandText SELECT ...然后不指定CommandType也能跑因为ADO会去分析文本内容。但让ADO猜测有两个代价一是每次执行都多一步推断开销二是碰到长得像表名又像SQL的过程名时可能猜错方向。比如CommandText是一个存储过程名同时这个存储过程名恰好和一个表名重复不指定adCmdStoredProc就可能被当成表操作处理。 CommandText的三种常见形态 cmd.CommandType adCmdText 执行SQL cmd.CommandText SELECT * FROM dbo.Payroll WHERE PayrollID1001 cmd.CommandType adCmdTable 直接读整张表 cmd.CommandText Payroll cmd.CommandType adCmdStoredProc 调用存储过程 cmd.CommandText dbo.usp_GetPayrollByIdCommandType影响的不只是解析效率还会影响Execute的返回行为。比如adCmdTable方式下ADO会把CommandText做成本地化查询并直接返回表数据而adCmdStoredProc方式下执行结果取决于存储过程内部到底有没有SELECT语句。无论哪种方式如果命令返回了记录集都必须用Set rs cmd.Execute来接住它否则记录集会泄漏。2.3 Execute的返回值看清要不要SetCommand.Execute有三种可能的返回情况执行UPDATE/INSERT/DELETE时返回Nothing执行SELECT或调用有SELECT的存储过程时返回Recordset对象执行带输出参数的存储过程时返回Recordset的同时还会把值填到Parameters集合里。初学者最常见的翻车就是该写Set没写或者不该写Set却写了。 返回记录集时必须用Set接住 Dim rs As ADODB.Recordset cmd.CommandText SELECT PayrollID, Amount FROM dbo.Payroll WHERE Status1 cmd.CommandType adCmdText Set rs cmd.Execute 少了Setrs里不会自动有数据 Do While Not rs.EOF Debug.Print rs(PayrollID), rs(Amount) rs.MoveNext Loop rs.Close 执行更新时不接返回值 cmd.CommandText UPDATE dbo.Payroll SET Status0 cmd.Execute 这里千万不能写Set rs cmd.Execute还有一点需要提前说通过Command.Execute拿到的Recordset默认是一个只向前的只读游标。你可以在里面MoveNext、读字段但不能直接修改数据也不能随意MovePrevious。如果需要可滚动、可更新的记录集常见做法是先把Command对象建好并配好参数然后用Recordset.Open去执行它而不是用Command.Execute。这个技巧到后面第6章会展开。使用场景推荐写法理由一次性执行UPDATE/DELETEconn.Execute代码短不需要参数带用户输入的SELECT/UPDATECommand 参数防止拼串出错和注入循环执行几千次同结构SQL复用同一个Command减少创建开销调用存储过程并拿输出参数Command ParametersConnection的Execute做不到需要可滚动可更新的结果集Recordset.Open cmd可同时用参数和游标能力3. 参数化查询用CreateParameter和Parameters.Append替换手拼SQL3.1 手拼SQL为什么总会翻车从连接字符串到CommandText如果一直靠字符串拼接处理用户的输入迟早遇到一个带单引号的名字就整个语法错误。比如用户名字是OBrien拼出来的SQL就成了WHERE UserNameOBrienSQL Server直接报错。更隐蔽的情况是用户输入了特殊字符查询结果和预期完全对不上。这个问题的根治办法是参数化查询把SQL里的具体值替换成参数占位符执行时再把值通过Parameters集合传给数据库。 翻车写法字符串拼接 sql SELECT * FROM dbo.Users WHERE UserName enteredName cn.Execute sql 参数化写法值不再进SQL文本 cmd.CommandText SELECT UserID, UserName, DeptName FROM dbo.Users WHERE UserName? AND DeptName? cmd.CommandType adCmdText cmd.Parameters.Append cmd.CreateParameter(UserName, adVarWChar, adParamInput, 50, OBrien) cmd.Parameters.Append cmd.CreateParameter(DeptName, adVarWChar, adParamInput, 50, 财务部) Set rs cmd.Execute这段代码里SQL文本中的问号是占位符ADODB的OLE DB提供程序按位置把Parameters集合里的值绑定到问号上。这里要特别强调SQL Server的OLE DB提供程序处理CommandText时占位符是?而不是UserName。很多从SQL Server Management Studio复制过来的SQL习惯性写着WHERE UserNameUserName直接用ADO执行会报参数未定义。调用存储过程时才直接用参数名那是第4章的事。3.2 CreateParameter的五个参数类型、方向、Size一个都不能少CreateParameter是给Command对象生成参数对象的方法签名是CreateParameter(Name, Type, Direction, Size, Value)。前四个参数都定义了参数的“形状”最后一个才是实际的输入值。新手最容易在Type和Size上踩坑。Name参数名主要用来在Parameters集合里按名字索引比如cmd.Parameters(UserName)。在SQL Server的CommandText占位符模式下参数名可以由你随便起位置才是关键。Type数据类型枚举。常用的有adInteger整型、adVarChar定长字符串、adVarWCharUnicode字符串、adDate日期、adDecimal小数。判断标准是数据库列的类型SQL Server的NVARCHAR列对应adVarWCharVARCHAR列对应adVarChar一旦Type和列类型不匹配会产生隐式转换轻则查询变慢重则中文乱码。Direction参数方向。adParamInput表示输入参数默认就是它adParamOutput用于存储过程的输出参数adParamInputOutput用于既是输入又是输出的参数adParamReturnValue用来接收存储过程的返回值。只做普通SQL查询时全部用adParamInput。Size参数的最大长度。对adVarChar和adVarWChar这种变长类型Size必须设置而且给的是列的宽度不是本次传入值的长度。SQL Server的OLE DB提供程序不会自动推断Size漏写或写小了会直接报“参数对象定义不正确”或者把字符串截断。对adInteger等定长类型Size可以省略。Value可选在创建参数的同时赋初始值。也可以Append后再单独赋值。 更稳妥的写法分段创建便于设置Size之外的属性 Dim p As ADODB.Parameter Set p cmd.CreateParameter(UserName, adVarWChar, adParamInput, 50) p.Value OBrien cmd.Parameters.Append p3.3 给参数赋值的两种写法与参数顺序参数赋值有两种常见写法一种是在CreateParameter的第五个参数直接传值另一种是Append之后再通过索引或名字赋值。两种写法等价但第二种更适合在循环里复用Command时用因为它的赋值动作和创建动作分离。 方式一CreateParameter带上初始值 cmd.Parameters.Append cmd.CreateParameter(p1, adInteger, adParamInput, , 1001) cmd.Parameters.Append cmd.CreateParameter(p2, adVarWChar, adParamInput, 50, 财务部) 方式二Append后单独赋值循环里常用 cmd.Parameters.Append cmd.CreateParameter(p1, adInteger, adParamInput) cmd.Parameters.Append cmd.CreateParameter(p2, adVarWChar, adParamInput, 50) cmd.Parameters(0).Value 1001 cmd.Parameters(1).Value 财务部参数顺序是一个隐藏很深的坑ADO在CommandText的占位符模式下按位置绑定SQL里第一个?对应Parameters集合里的第一个参数第二个?对应第二个参数以此类推。如果SQL先写UserName?后写DeptName?那么Append时也必须先追加UserName再追加DeptName。顺序对调后不报错但数据会写错列排查起来非常痛苦。这也是为什么我建议参数名仍然用心命名方便调试时用cmd.Parameters(UserName).Value来核对。还有一点需要留意开发调试时可以临时用cmd.Parameters.Refresh让ADO去数据库读参数定义能省去手写CreateParameter的麻烦。但这招只对存储过程有效对普通SQL无效而且Refresh会额外产生一次数据库往返生产环境里不要用。手动Append虽然啰嗦但稳定、可控尤其当存储过程的参数带默认值或输出参数时手动定义比Refresh可靠得多。4. Command对象进阶用法存储过程调用、事务与循环复用4.1 调用带输出参数和返回值的存储过程Command对象比Connection.Execute强的地方之一就是调用存储过程。除了执行过程本身还能拿到存储过程的输出参数和返回值。假设SQL Server里有一个统计部门薪资的存储过程CREATE PROCEDURE dbo.usp_GetSalaryStats DeptName NVARCHAR(50), Total DECIMAL(18,2) OUTPUT, Count INT OUTPUT AS BEGIN SELECT Total SUM(p.Amount), Count COUNT(*) FROM dbo.Payroll p JOIN dbo.Department d ON p.DeptID d.DeptID WHERE d.DeptName DeptName ENDVB侧用Command调用时CommandText写存储过程名CommandType设为adCmdStoredProc然后按存储过程的参数顺序依次Append。这里有个细节存储过程参数名前面的 符号在CreateParameter里要保留要和存储过程的定义一致。Set cmd New ADODB.Command Set cmd.ActiveConnection cn cmd.CommandType adCmdStoredProc cmd.CommandText dbo.usp_GetSalaryStats 按存储过程定义顺序追加参数 cmd.Parameters.Append cmd.CreateParameter(DeptName, adVarWChar, adParamInput, 50, 财务部) cmd.Parameters.Append cmd.CreateParameter(Total, adDecimal, adParamOutput, 18) cmd.Parameters.Append cmd.CreateParameter(Count, adInteger, adParamOutput) adDecimal类型还需要单独设置小数位数 Dim p As ADODB.Parameter Set p cmd.Parameters(Total) p.NumericScale 2 cmd.Execute 执行完之后才能读取输出参数的值 Debug.Print cmd.Parameters(Total).Value, cmd.Parameters(Count).Value这段代码有两个容易翻车的地方。第一adDecimal这类数值类型在CreateParameter里Size参数的含义是精度而不是字节数而且还需要额外设置NumericScale属性指定小数位。第二输出参数必须在Execute执行完成后再读在Execute之前读会拿到空值。执行成功但输出参数一直是Null时优先检查是不是读早了。如果存储过程本身还有RETURN返回值需要在Append所有参数之前先追加一个adParamReturnValue类型的参数执行后从它身上读整数类型的返回值。RETURN_VALUE习惯上放在参数集合的第一个位置这不算语法要求但能避免和某些Provider的行为起冲突。4.2 和事务配合让一批Command要么全成要么全回滚事务在ADO里是Connection对象的方法不是Command对象的方法。很多刚从SQL语句转到ADO的人会找cmd.BeginTrans根本没这个方法。事务的正确用法是先用cn开启事务再在这个连接上执行多个Command最后根据结果决定提交还是回滚。On Error GoTo ErrHandler cn.BeginTrans Set cmd.ActiveConnection cn cmd.CommandType adCmdText 第一笔扣款 cmd.CommandText UPDATE dbo.Account SET BalanceBalance-100 WHERE AccountID1001 cmd.Execute 第二笔入账 cmd.CommandText UPDATE dbo.Account SET BalanceBalance100 WHERE AccountID1002 cmd.Execute cn.CommitTrans Exit Sub ErrHandler: If cn.State adStateOpen Then cn.RollbackTrans同一个连接上的多个Command在事务内共享同一个隔离级别这意味着第1章提到“Command必须挂在Connection上”这件事在事务场景下显得尤其重要。如果你用字符串给ActiveConnection赋值ADO会隐式创建连接事务开关根本没法作用到那个看不见的连接上。事务场景下有个性能相关的小技巧开启事务后同一连接上的INSERT和UPDATE会少很多自动提交的开销。比如后面要说的循环插入配合事务能成倍提速。但要控制好单次事务的提交行数不要一个事务跑到几万行不提交否则锁和日志会把数据库拖死。我一般每500到1000行提交一次。4.3 循环里复用同一个Command执行批处理任务时最忌讳在循环体内反复New ADODB.Command。创建一个COM对象的开销虽然不算大但循环一千次、一万次之后差别就很明显了。正确的做法是在循环外创建一次Command循环里只修改CommandText或参数Value然后重复Execute。Set cmd New ADODB.Command Set cmd.ActiveConnection cn cmd.CommandType adCmdText cmd.CommandText INSERT INTO dbo.Payroll (EmpID, Amount) VALUES (?, ?) 追加参数一次之后只改Value cmd.Parameters.Append cmd.CreateParameter(EmpID, adInteger, adParamInput) cmd.Parameters.Append cmd.CreateParameter(Amount, adDecimal, adParamInput, 18) cmd.Parameters(Amount).NumericScale 2 Dim i As Long For i 1 To 1000 cmd.Parameters(EmpID).Value i cmd.Parameters(Amount).Value i * 100 cmd.Execute Next i复用Command对象时参数集合保持不变只需要给每个参数重新赋值。这个写法在循环里省去了参数对象的创建和销毁配合事务之后数据量在一万条以内基本可以做到秒级完成。如果循环里需要执行不同结构的SQL可以只改CommandText和CommandType但要注意如果SQL里的占位符数量或顺序变了Parameters集合不会自动调整你需要先清空再重新Append。清空用cmd.Parameters.Delete或者干脆重新New一个Command看代码可读性取舍。5. Command对象避坑指南5个让人查一下午的报错5.1 报“对象关闭时不允许操作”ActiveConnection没设或没打开现象cmd.Execute执行时运行时错误3704“对象关闭时不允许操作”。有时候代码明明写了cn.Open还是报这个错。 原因Set cmd.ActiveConnection这行被跳过或者赋的是一个没打开的新Connection对象还有一种情况是cmd在之前的操作中执行出错Connection被ADO自动关闭了。 解决在执行前加一段防御性判断确认连接状态。排查时先把Debug.Print cmd.ActiveConnection.State打出来看看是不是0adStateClosed。如果是对的对象但没打开补一个cmd.ActiveConnection.Open如果ActiveConnection是Nothing回到第2.1节重新赋值。5.2 数据写错列但不报错参数顺序和SQL占位符对不上现象UPDATE执行成功但受到影响的是另一条记录字段值张冠李戴。 原因ADO在CommandText的占位符模式下按参数在Parameters集合里的位置绑定不按参数名绑定。SQL里先出现的?永远对应Parameters集合里索引为0的参数。参数名只是方便阅读改变不了绑定顺序。 解决在循环执行前用Debug.Print cmd.CommandText和Debug.Print cmd.Parameters(i).Name cmd.Parameters(i).Value逐个打印肉眼核对顺序。更省事的办法是让SQL的编写顺序和Parameters.Append顺序保持一致并且写完一行SQL就对应着追加一行参数不要先写完SQL再回头补参数。5.3 CreateParameter忘了设置Size变长字符串参数报错现象执行时弹“参数对象定义不正确”或“参数信息不一致”把参数Type改来改去都解决不了。 原因adVarChar和adVarWChar是变长类型SQL Server的OLE DB提供程序要求Append时明确声明最大长度。Size没写或写0提供程序不知道分配多大的缓冲区直接拒绝执行。 解决给变长字符串类型的参数固定一个Size值是该字段允许的最大长度不是本次输入字符串的长度。比如数据库列是NVARCHAR(50)就写50如果字段升级成NVARCHAR(200)参数Size也要跟着改。这个参数值一旦设得太小字符串会被静默截断不会报错这种截断问题比报错更难发现。5.4 循环里反复New Command内存只涨不降现象循环五千次以上VBA或VB6进程内存持续上涨程序执行完内存也不降甚至卡死。 原因循环体内执行Set cmd New ADODB.Command每次创建的COM对象在循环变量释放前不会被完全回收如果还有Recordset没有Close引用链就更难断。 解决把Command移到循环外面创建循环里只改参数Value和CommandText每次Execute完成后立即把返回值如果有RecordsetSet成Nothing。循环结束后再统一Set cmd Nothing。如果是后期绑定写的CreateObject(ADODB.Command)这种释放不可控的问题更突出建议改用前期绑定。5.5 中文乱码或查不到数据VARCHAR和NVARCHAR隐式转换现象参数值明明是“财务部”传到SQL Server后变成乱码或者查询不到任何记录同一条SQL在SSMS里能查到在ADO里查不到。 原因CreateParameter里用了adVarChar而SQL Server的列是NVARCHAR类型。adVarChar对应的是数据库的VARCHAR编码不一致导致隐式转换中文在转换过程中丢失或变形。 解决跟中文文本打交道一律用adVarWChar对应SQL Server的NVARCHAR。另外还需要考虑SQL语句里的字符串字面量如果SQL里直接写WHERE DeptName财务部这个常量本身按数据库默认排序规则走也会和参数模式下的行为有差异。参数化后统一用adVarWChar就能避开这个坑。6. 把Command用到顺手Prepared、CommandTimeout与注入验证6.1 Prepared预编译SQL到底值不值cmd.Prepared True后ADO会在首次Execute时让数据库把命令预编译好之后的重复执行直接复用编译计划。对同一连接上反复执行、只改参数值的场景收益明显。但首次执行会多一次Prepare往返而且每次修改CommandText后Prepared状态会失效。如果一条SQL只执行一次设Prepared反而更慢。我通常只在循环插入或高频报表查询里打开它。cmd.Prepared True 循环执行同一SQL时有效6.2 CommandTimeout默认30秒经常不够CommandTimeout控制的是命令执行时间不是连接建立时间。做复杂报表或大量数据更新时默认30秒经常爆掉。把CommandTimeout调大是最直接的解决方案。注意Connection对象上也有一个CommandTimeout两者独立生效连接级别的不必改改Command自己的就够了。cmd.CommandTimeout 120 秒0表示无限期等待6.3 用一条注入字符串验证参数化是否真的生效想确认SQL真的被参数化了有个笨办法故意把一个带单引号和OR的字符串传进参数值然后看数据库反应。cmd.Parameters(UserName).Value OR 11-- Set rs cmd.Execute Debug.Print rs.RecordCount参数化生效时数据库会把整个字符串当成一个字面值去匹配查不到任何记录返回0行如果这句参数被直接拼进了SQL文本它会变成WHERE UserName OR 11--返回所有行。靠这个方法可以在改完代码后立刻验证参数绑定有没有真正生效。我每次做完Command改造都会跑一遍这个验证顺手再打印一次cmd.CommandText和参数列表存档。这种习惯救过我很多次希望帮到你。本文还有配套的精品资源点击获取