SQL查询在SSMS正常运行，VBA中ADODB调用报3704错误

针对你遇到的问题，结合ADODB与SQL Server临时表的常见坑，给出以下排查和解决建议：

1. 修正SQL查询的结果集输出 #

虽然查询在SSMS中能正常执行，但ADODB对SQL语句的结果集处理更严格：

• 添加SET NOCOUNT ON：修改后的查询可能包含INSERT/UPDATE等语句，这些语句会返回"影响行数"的消息，ADODB会将其视为独立结果集，导致后续的数据集无法被正确识别。在SQL开头加入：

  SET NOCOUNT ON;
  

• 确保最后语句返回数据集：如果查询包含多个批处理逻辑，要保证最后一条语句是SELECT目标数据的语句，避免无结果集返回。
• 移除GO命令：GO是SSMS的批处理分隔符，并非T-SQL语法，ADODB无法解析。若原查询用了GO，需将批处理合并为单个语句，或改用存储过程封装逻辑。

2. 调整ADODB连接与记录集配置 #

检查VBA中ADODB对象的参数设置：

• 设置客户端游标：将连接对象的CursorLocation设为adUseClient，避免服务器端游标导致的记录集异常关闭：

  Dim conn As ADODB.Connection
  Set conn = New ADODB.Connection
  conn.CursorLocation = adUseClient ' 关键设置
  conn.Open "你的连接字符串"
  

• 指定记录集打开参数：打开记录集时明确游标类型和命令类型，确保记录集能正确加载数据：

  Dim rs As ADODB.Recordset
  Set rs = New ADODB.Recordset
  rs.Open 你的SQL语句, conn, adOpenStatic, adLockReadOnly, adCmdText
  

3. 排查临时表作用域问题 #

如果修改后的查询依赖临时表，需注意ADODB的连接特性：

• 局部临时表（#开头）：必须在同一个连接会话中创建和读取，若查询中存在断开连接的逻辑（比如中间关闭过连接），临时表会被销毁。确保创建临时表和读取数据的语句在同一个连接实例中执行。
• 避免嵌套临时表逻辑：若临时表的创建依赖复杂的子查询或多步操作，可改用表变量（DECLARE @tempTable TABLE (...)）替代，表变量的作用域更稳定，ADODB支持更好。

4. 增加VBA调试与错误捕获 #

在VBA中添加状态检查，定位问题根源：

On Error Resume Next
rs.Open 你的SQL语句, conn
If Err.Number <> 0 Then
    Debug.Print "SQL执行错误：" & Err.Description
    Err.Clear
End If
On Error GoTo 0

If rs.State = adStateOpen Then
    ' 正常读取数据逻辑
    Sheet1.Range("A1").CopyFromRecordset rs
Else
    Debug.Print "记录集未打开，状态：" & rs.State
End If

内容的提问来源于stack exchange，提问作者Steve