oraclecommand执行后游标是否关闭不由c#主动控制，驱动在读取完结果集后自动发送close请求；但若datareader未用using包裹、dataset被长期引用或存储过程中open未执行，服务端游标仍会滞留。
OracleCommand执行后游标没关，不是因为没调Close()
Oracle 的 sys_refcursor 本质是服务端句柄，C# 侧调用 OracleCommand.ExecuteNonQuery() 或 OracleDataAdapter.Fill() 后，游标是否关闭，**不由 C# 主动控制**。驱动（如 Oracle.ManagedDataAccess）在读取完结果集后会自动发送 CLOSE 请求给 Oracle 服务端——但前提是：你没把 OracleDataReader 或 DataSet 持有太久，也没在连接池归还前让资源泄漏。
常见误判是以为“我调了 conn.Close() 就万事大吉”，其实：连接池的 Close() 只是归还物理连接，REF CURSOR 对应的服务端游标仍可能滞留在 v$open_cursor 中，尤其当 OracleDataAdapter 内部没完成 fetch、或 DataSet 被长期引用导致 GC 延迟释放时。
- 显式使用
OracleDataReader时，必须确保它被using包裹，否则Dispose()不触发，服务端游标不释放 -
OracleDataAdapter.Fill()是“一次性灌入”，内部会自动 open/fetch/close 游标，但若DataSet被缓存并反复访问Tables[0].Rows，某些旧版驱动会在第二次访问时尝试重 fetch —— 此时游标已关，报Invalid operation. The connection is closed.或静默失败 - 若存储过程中游标被
OPEN o_cursor FOR ...后又没走到CLOSE o_cursor（比如异常提前退出），Oracle 服务端不会帮你补关，这个游标就一直开着，直到会话结束
OracleDbType.RefCursor 参数没设 Value，但也不能随便设
注册输出游标参数时，OracleParameter 的 Direction 必须是 ParameterDirection.Output，且 OracleDbType 必须为 OracleDbType.RefCursor；但它的 Value 属性不能设为任何值（包括 null 或 DBNull.Value），否则驱动会抛 ORA-06502 或直接忽略该参数。
正确写法是只声明、不赋值：
var param = cmd.Parameters.Add("cur_out", OracleDbType.RefCursor);
param.Direction = ParameterDirection.Output;
如果误写成：
param.Value = DBNull.Value; // ❌ 错误：驱动无法处理
会导致存储过程执行时游标参数绑定失败，Oracle 端收不到有效句柄，自然无法 OPEN，后续客户端拿到空结果或报 Cursor is closed。
连接字符串缺 Unicode=True，游标能开但数据取不出来
即使游标成功 OPEN、Fill() 也无异常，DataSet.Tables[0].Rows.Count 仍为 0，很可能是字符集问题。Oracle.ManagedDataAccess 默认按非 Unicode 编码传输字符串，若存储过程中游标查询含中文字段、或数据库字符集为 AL32UTF8，而连接串没加 Unicode=True，驱动会在服务端隐式做字符转换，导致结果集元数据错乱或字段值为空。
务必检查连接字符串是否包含：
Data Source=...;User Id=...;Password=...;Unicode=True;
漏掉这一项，OracleDataAdapter 可能解析不出列名，Fill() 表面成功，实际生成的是无列、无行的空 DataTable。
存储过程里游标没真正 OPEN，客户端只能报“已关闭”
Cursor is closed 这个错误最误导人——它不是说“你关得太早”，而是“它压根没开过”。典型场景是存储过程逻辑分支中，OPEN o_cursor FOR ... 语句被 if 条件跳过，或在 OPEN 前抛了异常（如 SELECT INTO 未找到数据触发 NO_DATA_FOUND，且没被 EXCEPTION 捕获）。
验证方法很简单：用 SQL*Plus 或 SQL Developer 直接执行：
BEGIN PRO_TEST(5, :cur_out); -- 注意用变量接收 END;
再查 :cur_out 是否可 FETCH。如果连 PL/SQL 块里都 FETCH 不出数据，那 C# 层再怎么配参数都没用。
真正要盯住的，是存储过程里每一条 OPEN 语句的执行路径，而不是 C# 的 using 套了几层。
