OracleCommand调用带返回值函数时，ParameterDirection.ReturnValue必须显式设置，否则返回值为null；需用ExecuteScalar()或BEGIN...END;块配合ReturnValue参数获取结果，且类型、生命周期、绑定时机须严格匹配。
OracleCommand调用带返回值函数时，ParameterDirection.ReturnValue必须显式设置
oracle 函数（非存储过程）的返回值不是自动捕获的，哪怕你写了 select my_func(...) from dual，在 ado.net 里也得靠参数绑定来拿。很多人卡在这儿：函数明明执行成功，但 cmd.parameters[0].value 是 null 或 dbnull.value —— 根本没设方向。
实操建议：
- 声明参数时，
OracleParameter的Direction必须设为ParameterDirection.ReturnValue，不能依赖默认值（默认是Input） - 函数名要写全，包括 schema，比如
"SCOTT.MY_CALC_FUNC"；如果没加 schema，且当前用户不是 owner，可能报ORA-00904: invalid identifier - 别用
ExecuteNonQuery()—— 它不处理返回值；该用ExecuteScalar()或先ExecuteNonQuery()再读参数，但后者只适用于函数被包装进 PL/SQL 块中（见下一条）
用 ExecuteNonQuery() 调函数？得包一层 BEGIN ... END;
直接对函数调用 ExecuteNonQuery() 会报 ORA-00900: invalid SQL statement，因为 Oracle 不允许把函数调用当独立语句执行。想用 ExecuteNonQuery()，就得把它塞进匿名 PL/SQL 块里。
实操建议：
- SQL 文本写成：
"BEGIN :ret := SCOTT.MY_FUNC(:p1, :p2); END;" - 其中
:ret是带ParameterDirection.ReturnValue的参数，:p1、:p2是普通Input参数 -
ExecuteNonQuery()执行后，立刻读param_ret.Value，不要等连接关闭或命令重用 - 注意：这种写法在高并发下比纯 SQL 调用略重，因为多了 PL/SQL 解析开销，但兼容性更好（尤其老版本 OracleClient）
OracleDbType 和 .NET 类型不匹配，导致 InvalidCastException 或截断
Oracle 函数返回 NUMBER，你却用 OracleDbType.Varchar2 接，或者返回 VARCHAR2(200) 却只分配了 Size = 10，轻则值被截断，重则抛 InvalidCastException 或 ORA-06502。
实操建议：
- 查清函数定义里的返回类型：用
DESCRIBE SCOTT.MY_FUNC或看包头，别猜 - 对应关系要盯紧：
NUMBER→OracleDbType.Decimal或OracleDbType.Int32（按实际精度选），VARCHAR2→OracleDbType.Varchar2并设足Size - 返回
CLOB时，OracleDbType.Clob+Size = -1，且必须用ExecuteScalar()或从ReturnValue参数取，不能当字符串直接赋值 - 如果函数返回布尔（PL/SQL 中的
BOOLEAN），.NET 无法直译 —— 得改函数，返回NUMBER(1)或VARCHAR2(1)代替
Connection 和 Command 生命周期搞混，ReturnValue 变成 null
参数对象脱离了所属的 OracleCommand，或者命令执行完、连接关了再去读 Value，结果永远是 null。这不是 bug，是 ADO.NET 的资源管理逻辑。
实操建议：
-
OracleParameter必须通过cmd.Parameters.Add()挂到命令上，不能 new 一个就自己拿着 - 执行完
ExecuteNonQuery()或ExecuteScalar()后，**立刻**读param.Value，别等 using 块结束 - 别在 finally 里读返回值 —— 如果 try 里出异常，参数可能根本没被 Oracle 填充
- 如果用了 connection pooling，更要小心：参数对象不能跨 command 复用，每次新调用都 new 新参数
最常被忽略的是参数绑定时机和读值时机之间的毫秒级错位 —— 看似顺序写了，但中间插了日志、异步等待或连接状态检查，就容易丢值。
