为何按存储过程规范传参仍报ORA-06550与PLS-00306错误？

这个错误通常意味着你的调用语句和存储过程定义之间存在参数不匹配的情况——哪怕你觉得参数类型都对，也可能有一些容易忽略的细节在搞鬼。结合你的存储过程定义，我整理了几个最可能的排查方向：

1. 注意参数名的大小写问题 #

你的存储过程参数用双引号括起来了（比如"p_name"），这在Oracle里会强制参数名区分大小写。默认情况下，Oracle会把未加引号的标识符转为大写，所以如果你调用时写的是p_name => 'xxx'（没加引号），Oracle会把它解析成P_NAME，但存储过程里定义的是小写的"p_name"，两者不匹配，就会被误认为是参数数量或类型错误。

解决方法：

• 调用时严格匹配参数名的大小写，并且加上双引号：

  add_rule_range_attr(
      "p_name" => '你的规则名称',
      "p_entity" => '实体名称',
      "p_attribute" => '属性名称',
      "p_r_negate" => 0,
      "p_ra_comparer1" => '>',
      "p_ra_comparer2" => '<'
  );
  

• 或者如果不需要区分大小写，可以修改存储过程定义，去掉参数名的双引号：

  PROCEDURE add_rule_range_attr(
      p_name IN VARCHAR2,
      p_entity IN VARCHAR2,
      p_attribute IN VARCHAR2,
      p_r_negate IN NUMBER,
      p_ra_comparer1 IN VARCHAR2,
      p_ra_comparer2 IN VARCHAR2
  );
  

  这样调用时就不用纠结大小写了。

2. 检查参数传递的顺序和数量 #

如果调用时没有显式指定参数名（比如直接按顺序传值），必须严格遵循存储过程定义的参数顺序：p_name → p_entity → p_attribute → p_r_negate → p_ra_comparer1 → p_ra_comparer2。哪怕只是顺序搞反了一个，比如把p_r_negate的位置传成了字符串，就会触发类型不匹配的错误。

建议：尽量使用参数名 => 值的方式调用，这样既清晰又不容易出错。

3. 验证参数的实际类型 #

虽然你觉得类型匹配，但还是要确认：

• p_r_negate是NUMBER类型，确保传递的是数字（比如1、0），而不是字符串形式的数字（比如'1'）。虽然Oracle有时候会隐式转换，但在严格模式下或者某些环境中，这种转换会失败。
• 所有VARCHAR2类型的参数，确保传递的是字符串类型，不要传递数字或其他类型（除非你确定隐式转换没问题，但不推荐依赖这个）。

4. 排查外部调用的类型映射问题 #

如果是在Java、Python等外部语言中调用这个存储过程，要确保驱动程序传递的参数类型和Oracle的类型正确映射：

• 比如Java中用setString()对应VARCHAR2参数，setInt()或setLong()对应NUMBER参数；
• Python中用cx_Oracle的话，确保传递的参数类型和存储过程定义一致，比如数字类型用int/float，字符串用str。

5. 检查存储过程的重载情况 #

如果存在同名但参数不同的存储过程重载，Oracle可能会匹配到错误的重载版本，导致参数不匹配。可以通过查询视图确认存储过程的定义是否和你预期一致：

SELECT * FROM USER_PROCEDURES WHERE OBJECT_NAME = 'ADD_RULE_RANGE_ATTR';
SELECT * FROM USER_ARGUMENTS WHERE OBJECT_NAME = 'ADD_RULE_RANGE_ATTR';

按照这些步骤排查，应该能找到问题所在。

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