PHP7从mssql扩展迁移到sqlsrv后调用存储过程执行失败如何解决

第一步：先打开完整错误输出定位根因 #

你当前代码中已经加了sqlsrv_errors()输出，但注释了die，先取消注释，优先读取错误返回的具体信息：

• 错误返回中的SQLSTATE值可以直接定位问题分类，比如42000是SQL语法错误，IMSSP是sqlsrv扩展本地错误，22018是数据类型不匹配
• 优先根据错误码定位问题，不要盲目猜测

第二步：修正存储过程调用语法 #

sqlsrv扩展要求调用存储过程必须使用ODBC转义的CALL语法，你现有写法直接写存储过程名会被解析为普通SQL语句，属于高频踩坑点。
修正后的调用语法格式：

// 格式1：ODBC标准转义写法，兼容性最好
$stmt = sqlsrv_prepare($mssql_db, "{CALL Deletion_Request_Execute(?)}", $params);
// 格式2：显式EXEC写法，也可正常执行
$stmt = sqlsrv_prepare($mssql_db, "EXEC Deletion_Request_Execute @Lead_ID = ?", $params);

第三步：显式绑定参数类型匹配原有SQLVARCHAR约束 #

sqlsrv支持在参数数组中显式指定参数类型、长度，完全对应原来mssql_bind的能力，不需要只传变量引用。假设你的存储过程中@Lead_ID定义为VARCHAR(36)（根据实际长度调整），参数写法如下：

$params = array(
    array(
        &$lead_id, 
        SQLSRV_PARAM_IN, 
        SQLSRV_PHPTYPE_STRING(SQLSRV_ENC_CHAR), 
        SQLSRV_SQLTYPE_VARCHAR(36)
    )
);

• SQLSRV_PARAM_IN指定为输入参数，对应原mssql_bind最后一个false的非输出参数设置
• SQLSRV_PHPTYPE_STRING指定PHP侧传入字符串类型，对应你之前做的strval转换
• SQLSRV_SQLTYPE_VARCHAR(36)指定SQL侧的参数类型长度，完全匹配原SQLVARCHAR约束

第四步：额外基础校验项 #

• 先校验$mssql_db连接资源是否有效，迁移时连接逻辑调整容易出现连接失败的问题，执行var_dump($mssql_db)如果返回false说明连接本身有问题，优先排查连接配置
• 如果存储过程有返回值或者输出参数，需要对应补充参数配置，不要直接复用旧版mssql的无返回写法

完整可运行参考代码 #

// 先校验连接有效性
if ($mssql_db === false) {
    die(print_r(sqlsrv_errors(), true));
}

$lead_id = strval($lead_id); // 提前转字符串保证PHP侧类型正确
$params = array(
    array(
        &$lead_id, 
        SQLSRV_PARAM_IN, 
        SQLSRV_PHPTYPE_STRING(SQLSRV_ENC_CHAR), 
        SQLSRV_SQLTYPE_VARCHAR(36) // 替换为你存储过程中@Lead_ID的实际长度
    )
);

$stmt = sqlsrv_prepare($mssql_db, "{CALL Deletion_Request_Execute(?)}", $params);
if ($stmt === false) {
    die("Prepare failed: " . print_r(sqlsrv_errors(), true));
}

if (!sqlsrv_execute($stmt)) {
    echo "Deletion_Request_Execute has failed!";
    echo 'Errors:<pre>'; var_dump(sqlsrv_errors());
    die;
}

// 执行完成后释放语句资源，对应原mssql_free_statement
sqlsrv_free_stmt($stmt);

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