企业官网建设流程全解析

简介：对于需要在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还是先有Command

Command对象不是独立的执行器，它必须挂在一个已经打开的数据库连接上工作。最常见也是最推荐的做法是：先创建并打开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 = "Provider=SQLOLEDB.1;Data Source=127.0.0.1;Initial Catalog=TestDB;User ID=sa;Password=123456;" cn.Open Set cmd = New ADODB.Command Set cmd.ActiveConnection = cn ' 把已打开的连接挂给Command cmd.CommandText = "UPDATE dbo.Payroll SET Status=1 WHERE PayrollID=1001" 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 PayrollID=1001" cmd.CommandType = adCmdTable ' 直接读整张表 cmd.CommandText = "Payroll" cmd.CommandType = adCmdStoredProc ' 调用存储过程 cmd.CommandText = "dbo.usp_GetPayrollById"

CommandType影响的不只是解析效率，还会影响Execute的返回行为。比如adCmdTable方式下，ADO会把CommandText做成本地化查询并直接返回表数据；而adCmdStoredProc方式下，执行结果取决于存储过程内部到底有没有SELECT语句。无论哪种方式，如果命令返回了记录集，都必须用Set rs = cmd.Execute来接住它，否则记录集会泄漏。

2.3 Execute的返回值：看清要不要Set

Command.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 Status=1" cmd.CommandType = adCmdText Set rs = cmd.Execute ' 少了Set，rs里不会自动有数据 Do While Not rs.EOF Debug.Print rs("PayrollID"), rs("Amount") rs.MoveNext Loop rs.Close ' 执行更新时不接返回值 cmd.CommandText = "UPDATE dbo.Payroll SET Status=0" cmd.Execute ' 这里千万不能写Set rs = cmd.Execute

还有一点需要提前说：通过Command.Execute拿到的Recordset，默认是一个只向前的只读游标。你可以在里面MoveNext、读字段，但不能直接修改数据，也不能随意MovePrevious。如果需要可滚动、可更新的记录集，常见做法是先把Command对象建好并配好参数，然后用Recordset.Open去执行它，而不是用Command.Execute。这个技巧到后面第6章会展开。

3. 参数化查询：用CreateParameter和Parameters.Append替换手拼SQL

3.1 手拼SQL为什么总会翻车

从连接字符串到CommandText，如果一直靠字符串拼接处理用户的输入，迟早遇到一个带单引号的名字就整个语法错误。比如用户名字是O'Brien，拼出来的SQL就成了WHERE UserName='O'Brien'，SQL 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, "O'Brien") 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 UserName=@UserName，直接用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（定长字符串）、adVarWChar（Unicode字符串）、adDate（日期）、adDecimal（小数）。判断标准是数据库列的类型：SQL Server的NVARCHAR列对应adVarWChar，VARCHAR列对应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 = "O'Brien" cmd.Parameters.Append p

3.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 END

VB侧用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 Balance=Balance-100 WHERE AccountID=1001" cmd.Execute ' 第二笔：入账 cmd.CommandText = "UPDATE dbo.Account SET Balance=Balance+100 WHERE AccountID=1002" 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打出来，看看是不是0（adStateClosed）。如果是对的对象但没打开，补一个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完成后立即把返回值（如果有Recordset）Set成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 1=1--" Set rs = cmd.Execute Debug.Print rs.RecordCount

参数化生效时，数据库会把整个字符串当成一个字面值去匹配，查不到任何记录，返回0行；如果这句参数被直接拼进了SQL文本，它会变成WHERE UserName='' OR 1=1--'，返回所有行。靠这个方法可以在改完代码后立刻验证参数绑定有没有真正生效。我每次做完Command改造，都会跑一遍这个验证，顺手再打印一次cmd.CommandText和参数列表存档。这种习惯救过我很多次，希望帮到你。

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