调用DB2存储过程触发BadSqlGrammarException：描述符索引无效(10>9)

错误核心原因 #

报错Descriptor index not valid. (10>9)说明你的CallableStatement实例认为当前仅存在9个参数占位符，但你尝试设置第10个参数，触发了索引越界。结合你提到存储过程有13个输入参数、代码中已设置13个参数的情况，重点排查以下几点：

1. 检查存储过程调用的SQL字符串 #

这是最常见的问题：创建CallableStatement时编写的调用语句中，参数占位符（?）的数量与存储过程参数数量不匹配。例如如果你的调用SQL是：

String sql = "{call STORED_PROCEDURE_PROCESS_ONE_TIME(?, ?, ?, ?, ?, ?, ?, ?, ?)}";
CallableStatement cs = connection.prepareCall(sql);

这里仅包含9个?，自然只能设置前9个参数，第10个参数的设置就会报错。必须确保SQL中的占位符数量和存储过程的13个输入参数完全一致，修改为13个?：

String sql = "{call STORED_PROCEDURE_PROCESS_ONE_TIME(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}";

2. 确认数据库中存储过程的实际参数定义 #

有可能你手头的存储过程文档是旧版本，或者数据库中的存储过程已被修改，实际参数数量仅为9个。登录DB2数据库，执行以下SQL查询存储过程的真实参数列表：

SELECT 
    PARAMNAME, 
    TYPENAME, 
    PARAMETERMODE 
FROM SYSCAT.PARMS 
WHERE PROCNAME = 'STORED_PROCEDURE_PROCESS_ONE_TIME' 
ORDER BY ORDINALPOSITION;

检查返回的记录数是否为13个，同时核对参数的顺序、类型是否与代码中的设置匹配。

3. 检查前9个参数的设置是否合法 #

如果前9个参数的类型设置错误（比如用setInt()设置字符串类型参数），可能导致JDBC驱动解析参数时出现异常，间接影响参数索引的计数。逐一核对前9个参数的设置方法：

• 确保setXXX()方法的类型与存储过程参数类型匹配，例如存储过程第9个参数是VARCHAR，就用setString()，不要误用setInt()。
• 检查参数设置时是否出现未捕获的异常，导致后续参数设置的上下文出错。

验证步骤 #

1. 修正调用SQL的占位符数量后，重新运行代码，观察是否仍报错。
2. 若问题依旧，使用DB2客户端直接调用存储过程（例如CALL STORED_PROCEDURE_PROCESS_ONE_TIME(参数1, 参数2, ..., 参数13)），确认存储过程本身能否正常执行，排除存储过程定义的问题。

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