63、SQL Server存储过程调用：EXECUTE、输出参数、结果集处理、错误处理

存储过程这东西，说白了就是数据库里的「函数」。你把一堆SQL逻辑打包好，起个名字，以后直接调用就行。我在项目中见过太多人把复杂业务逻辑写在应用层，几百行代码来回传数据，性能差得离谱。其实很多场景下，用存储过程一把梭，效率能翻好几倍。

今天咱们就聊聊怎么在C语言里调用SQL Server的存储过程。嗯，核心就四个点：EXECUTE调用、输出参数、结果集处理、错误处理。把这四个玩明白了，你就能在C代码里把数据库拿捏得死死的。

一、基础调用：EXECUTE 直调

最简单的场景——存储过程没有参数，或者只有输入参数。你直接用 EXECUTE 或者 EXEC 关键字就行。

举个例子，假设有个存储过程叫 sp_GetAllUsers：

// C代码片段 - 使用ODBC调用无参存储过程
SQLHSTMT hstmt;
SQLExecDirect(hstmt, (SQLCHAR*)"{CALL sp_GetAllUsers}", SQL_NTS);

// 或者用EXECUTE语法
SQLExecDirect(hstmt, (SQLCHAR*)"EXEC sp_GetAllUsers", SQL_NTS);

我个人习惯用 {CALL ...} 这种转义语法，因为它在ODBC里更标准，跨数据库移植性也好一点。不过如果你确定只用SQL Server，直接写 EXEC 也没毛病。

二、输出参数：怎么把值带回来？

很多存储过程会带 OUTPUT 参数，比如返回一个状态码、总记录数之类的。在C语言里处理这个，需要先绑定参数，指定方向是 SQL_PARAM_OUTPUT。

我记得有一次做订单系统，需要调用一个存储过程来生成订单号，它通过输出参数返回新生成的ID。当时我忘了绑定输出参数，结果拿到的永远是垃圾值，排查了半天才发现问题。

// 假设存储过程: CREATE PROC sp_AddOrder @custId INT, @newId INT OUTPUT

SQLHSTMT hstmt;
SQLINTEGER custId = 1001;
SQLINTEGER newId = 0;
SQLLEN cbNewId = 0;

// 绑定输入参数
SQLBindParameter(hstmt, 1, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &custId, 0, NULL);

// 绑定输出参数 —— 注意方向是 SQL_PARAM_OUTPUT
SQLBindParameter(hstmt, 2, SQL_PARAM_OUTPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &newId, 0, &cbNewId);

// 执行
SQLExecDirect(hstmt, (SQLCHAR*)"{CALL sp_AddOrder(?, ?)}", SQL_NTS);

// 执行完后，newId 里就是存储过程返回的值
printf("新订单ID: %d\n", newId);

三、结果集处理：多条记录的读取

存储过程最常见的场景是返回结果集——比如 SELECT * FROM Users。在C语言里，你执行完存储过程后，就跟执行普通查询一样，用 SQLFetch 逐行读取。

但有个坑：存储过程可能返回多个结果集。比如它先 SELECT 了一些统计信息，再 SELECT 明细数据。这时候你需要用 SQLMoreResults 来切换到下一个结果集。

// 处理多结果集的典型循环
SQLHSTMT hstmt;
// ... 执行存储过程 ...

int rc;
do {
    // 绑定当前结果集的列
    // ... SQLBindCol ...
    
    // 读取当前结果集的所有行
    while (SQLFetch(hstmt) == SQL_SUCCESS) {
        // 处理每一行数据
    }
    
    // 尝试切换到下一个结果集
    rc = SQLMoreResults(hstmt);
} while (rc == SQL_SUCCESS);

// 如果 rc == SQL_NO_DATA，说明所有结果集都处理完了

你想想看，如果不处理多结果集，后面的数据就丢了。我曾经在一个报表项目里，存储过程返回了三个结果集，我只处理了第一个，结果报表数据少了一大半。嗯，从那以后我写存储过程调用都会加个循环。

四、错误处理：别让程序默默崩溃

C语言调用数据库，最怕的就是出错没提示。ODBC提供了 SQLError（旧版）或 SQLGetDiagRec（推荐）来获取详细的错误信息。

我建议每个 SQLExecDirect、SQLFetch 调用后面都跟一个错误检查。别嫌麻烦，线上问题排查时，这几行代码能救你的命。

// 错误处理函数示例
void CheckError(SQLHSTMT hstmt, SQLRETURN ret) {
    if (ret != SQL_SUCCESS && ret != SQL_SUCCESS_WITH_INFO) {
        SQLCHAR sqlState[6];
        SQLCHAR msg[SQL_MAX_MESSAGE_LENGTH];
        SQLINTEGER nativeError;
        SQLSMALLINT msgLen;
        
        SQLGetDiagRec(SQL_HANDLE_STMT, hstmt, 1, 
                      sqlState, &nativeError, msg, sizeof(msg), &msgLen);
        
        fprintf(stderr, "SQL错误: [%s] %s (错误码: %d)\n", 
                sqlState, msg, nativeError);
        // 根据情况决定是否退出
    }
}

// 使用示例
SQLRETURN ret = SQLExecDirect(hstmt, ...);
CheckError(hstmt, ret);

五、知识体系总览

下面这张图把今天讲的内容串起来了。你可以看到，从C程序发起调用，到最终拿到结果或错误，整个流程是环环相扣的。

六、实战避坑指南

最后分享几个我踩过的坑，希望能帮你省点时间：

• 参数顺序必须一致：存储过程定义的参数顺序，和你绑定的参数顺序，必须一模一样。别以为名字一样就行，ODBC是按位置匹配的。
• 输出参数要提前绑定：必须在 SQLExecDirect 之前绑定输出参数，执行完之后直接读变量。别想着执行完再绑定，那拿不到值。
• 结果集没读完就调用下一个存储过程：如果你在一个连接上执行了存储过程，结果集还没 fetch 完，又去执行另一个，前一个结果集会被丢弃。我曾经因为这个丢过数据，排查了好久才发现是连接复用的问题。
• 事务控制别忘：存储过程内部可能开了事务，如果C程序里没处理好提交/回滚，会导致锁等待。建议在C代码里显式调用 SQLSetConnectAttr 设置自动提交模式。

好了，关于存储过程调用的四个核心点就聊到这儿。代码不多，但每个点都是实战中容易出问题的地方。你写的时候多留个心眼，基本就不会翻车。