Oracle 11g环境下JDBC调用带OUT REF_CURSOR的存储过程更新计数异常为-1

嘿，这个问题我之前在项目里踩过坑！咱们先搞懂为什么会返回-1，再一步步解决。

核心原因：结果集优先覆盖更新计数 #

在Oracle JDBC的逻辑里，当存储过程同时包含DML更新操作和OUT REF_CURSOR输出参数时，JDBC会优先识别到REF_CURSOR对应的结果集。根据JDBC规范，当执行的语句产生结果集时，executeUpdate()会直接返回-1（表示存在结果集，而非更新计数），这就是你看到的异常现象。

正确的解决步骤 #

1. 改用execute()方法，先获取更新计数再处理游标 #

不要直接用executeUpdate()，而是用execute()执行存储过程，先调用getUpdateCount()拿到真实的更新数，再处理REF_CURSOR结果集。示例代码：

// 准备调用语句
CallableStatement cstmt = conn.prepareCall("{call your_target_procedure(?, ?)}");

// 设置IN参数
cstmt.setInt(1, your_input_id);
// 注册OUT REF_CURSOR参数（注意OracleTypes.CURSOR的引用）
cstmt.registerOutParameter(2, OracleTypes.CURSOR);

// 执行存储过程，返回是否存在结果集
boolean hasResultSet = cstmt.execute();

// 第一步：获取真实的更新计数
int actualUpdateCount = cstmt.getUpdateCount();
System.out.println("实际更新行数：" + actualUpdateCount); // 这里就能拿到预期的1了

// 第二步：处理REF_CURSOR结果集
if (hasResultSet) {
    ResultSet rs = (ResultSet) cstmt.getObject(2);
    // 这里写你的结果集处理逻辑，比如遍历数据
    while (rs.next()) {
        // 读取字段：rs.getString("column_name")
    }
    rs.close();
}

// 关闭资源
cstmt.close();

2. 检查存储过程的执行顺序 #

确保你的存储过程是先执行DML更新，再打开REF_CURSOR。如果顺序反过来，JDBC会先识别到结果集，导致更新计数无法被正确捕获。正确的存储过程结构示例：

CREATE OR REPLACE PROCEDURE your_target_procedure(
    p_input_id IN NUMBER,
    p_out_cursor OUT SYS_REFCURSOR
) AS
BEGIN
    -- 先执行DML更新操作
    UPDATE your_table SET status = 'UPDATED' WHERE id = p_input_id;
    -- 再打开REF_CURSOR返回结果
    OPEN p_out_cursor FOR SELECT * FROM your_table WHERE id = p_input_id;
END;
/

3. 注意ojdbc版本兼容性 #

你用的是ojdbc8搭配Oracle 11g，虽然ojdbc8向下兼容11g，但它主要是为Oracle 12c+设计的。如果上述方法无效，可以尝试换成ojdbc6（Oracle 11g的专属驱动，支持Java 6+，和Java 8兼容）。不过更推荐坚持用ojdbc8的正确用法，因为ojdbc6已经停止官方维护了。

4. 关闭自动提交避免干扰 #

如果你的数据库连接开启了自动提交，可能会干扰更新计数的获取逻辑。建议在执行存储过程前关闭自动提交，处理完后手动提交：

conn.setAutoCommit(false);
// 执行存储过程、处理结果...
conn.commit();

验证方法 #

你可以在存储过程里加上DBMS_OUTPUT.PUT_LINE(SQL%ROWCOUNT);，确认存储过程本身确实更新了1行数据，排除存储过程本身的问题。然后再用上面的JDBC代码验证，就能拿到正确的更新计数了。

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