使用ADO.NET调用存储过程返回异常结果，单独执行存储过程正常

我帮你梳理几个最常见的排查方向，都是ADO.NET调用存储过程时容易踩的坑，你可以逐一验证：

1. 务必设置CommandType为StoredProcedure #

这是最容易忽略的关键点！如果你的SqlCommand没有明确指定CommandType = CommandType.StoredProcedure，ADO.NET会把存储过程名当成普通SQL语句执行，大概率会返回不符合预期的结果。

给你补全代码里缺失的关键部分：

public DataTable ExecuteStoredProcedure(string name, params SqlParameter[] parameters) 
{ 
    var dataTable = new DataTable(); 
    var mode = _configurationService.AppSetting("mode"); 
    var connectionString = _configurationService.ConnectionString($"{mode}ConnectionString"); 
    using (var sqlConnection = new SqlConnection(connectionString))
    using (var sqlCommand = new SqlCommand(name, sqlConnection))
    {
        // 这行必须加！否则ADO.NET会把存储过程名当SQL字符串执行
        sqlCommand.CommandType = CommandType.StoredProcedure;
        sqlCommand.Parameters.AddRange(parameters);
        
        using (var adapter = new SqlDataAdapter(sqlCommand))
        {
            adapter.Fill(dataTable);
        }
    }
    return dataTable;
}

2. 检查参数传递是否完全匹配 #

• 确认每个SqlParameter的参数名和存储过程定义的完全一致（虽然SQL Server默认不区分大小写，但严格对应能避免意外问题）
• 验证参数的SqlDbType是否正确，比如把int类型参数错误定义成varchar，存储过程的隐式转换会导致结果异常
• 如果有输出/返回值参数，必须指定ParameterDirection.Output或ParameterDirection.ReturnValue，否则无法获取正确值

示例：如果存储过程有输出参数，参数定义应该是这样：

var totalCountParam = new SqlParameter("@TotalCount", SqlDbType.Int)
{
    Direction = ParameterDirection.Output
};

3. 确认连接字符串指向的数据库和手动执行的一致 #

你代码里用mode切换连接字符串，要排查ADO.NET使用的数据库和你手动执行EXEC dbo.AddressSearch的数据库是不是同一个！比如你在SSMS里查的是开发库，但代码里用了测试库的连接，结果自然不一样。

可以临时加个日志输出当前连接字符串，或者直接打印验证：

Console.WriteLine($"当前使用的连接字符串：{connectionString}");

4. 检查存储过程的会话依赖设置 #

有些存储过程会依赖当前会话的配置，比如SET ANSI_NULLS、SET QUOTED_IDENTIFIER或者语言设置，ADO.NET的默认配置可能和你在SSMS里的设置不同，导致存储过程执行逻辑变化。

解决方法有两种：

• 在存储过程开头显式设置必要的选项：

SET ANSI_NULLS ON
SET QUOTED_IDENTIFIER ON

• 或者在ADO.NET调用存储过程前，先执行对应的SET语句（不过更推荐第一种方式）

5. 捕获ADO.NET实际发送的SQL命令 #

如果以上都没问题，可以用SQL Server Profiler或者Extended Events捕获ADO.NET发送到数据库的命令，和你手动执行的语句对比，看有没有差异。

重点跟踪RPC:Completed事件（调用存储过程时的事件），就能看到ADO.NET到底向数据库发送了什么请求。

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