Oracle存储过程返回多个REF CURSOR时，.NET需用OracleCommand.Parameters显式声明输出参数
在.NET环境中调用Oracle存储过程，特别是涉及多个REF CURSOR返回的场景，开发者很容易遇到陷阱。一个关键区别在于：Oracle与开发者熟悉的SQL Server不同，它不会自动推断输出游标的类型。这意味着，在.NET代码中，你必须为每一个REF CURSOR显式声明OracleParameter，并将Direction设置为Output，OracleDbType指定为RefCursor。任何一个遗漏，都会在运行时触发ORA-01008: not all variables bound错误，或直接抛出InvalidOperationException异常。
一个典型的错误场景是：开发者只声明了输入参数，却忘记为每个OUT SYS_REFCURSOR预留占位参数。以下才是正确的做法：
cmd.Parameters.Add("p_cursor1", OracleDbType.RefCursor).Direction = ParameterDirection.Output;
cmd.Parameters.Add("p_cursor2", OracleDbType.RefCursor).Direction = ParameterDirection.Output;
调用后必须按顺序依次读取每个游标，不可跳过或重用DataReader
那么，调用之后如何正确读取这些游标呢？OracleCommand.ExecuteReader()返回的OracleDataReader支持NextResult()方法，用于切换到下一个结果集。但前提是所有游标已从数据库端完整返回。这里有一个关键点：如果存储过程中某个游标因为条件分支未执行而未被OPEN，对应位置的NextResult()调用仍然会成功，只是后续的Read()会一直返回false，并不会报错。因此，安全的做法是每次调用NextResult()后，先检查HasRows属性，再决定是否读取。
- 第一个游标：通过reader.Read()循环读取，读取完毕后调用reader.NextResult()
- 第二个游标：同样先检查if (reader.HasRows)再读取，否则直接跳过
- 注意，不能对同一个reader重复调用NextResult()超出游标数量，否则会抛出InvalidOperationException，提示“There is no current resultset.”
使用Oracle.ManagedDataAccess时，连接字符串需启用Unicode与连接池
如果游标中包含中文或特殊字符，未启用Unicode会导致乱码，这是一个不容忽视的问题。此外，如果关闭了连接池，每次调用都会新建连接，不仅影响性能，还可能触发Oracle的会话数量限制。
推荐的连接字符串配置如下：
Data Source=ORCL;User Id=usr;Password=pwd;Unicode=True;Connection Timeout=30;Pooling=true;Min Pool Size=5;Max Pool Size=50;
其中Unicode=True是必须的，它能确保驱动将NVARCHAR2、CLOB等字段正确映射为.NET中的string，否则很可能得到byte[]或乱码数据。
多游标场景下，避免使用DataSet.Fill()自动映射——列名大小写与NULL处理易出错
许多开发者习惯通过DataSet.Fill()批量读取数据，但在多游标场景下，这种做法可能带来隐患。OracleDataAdapter.Fill(DataSet)会尝试将每个游标映射为独立的DataTable，但该过程依赖Oracle返回的元数据。而Oracle默认列名全部大写，在.NET中DataTable.Columns["ID"]和["id"]并不等价。更棘手的是，如果某列全部为NULL，Oracle可能不返回该列的类型信息，导致Fill()抛出InvalidCastException。
更稳妥的方式是手动读取，具体做法如下：
- 使用reader.GetSchemaTable()确认列名与数据类型
- 通过reader.GetValue(i)或reader.GetString(i)按索引取值，避免大小写敏感问题
- 对于可能为NULL的字段，统一使用reader.IsDBNull(i)判断，而非直接调用GetString
最后，务必注意：Oracle按照声明顺序绑定参数，而非按名称匹配。因此，当多个游标逻辑紧密耦合时，游标的打开顺序与参数的绑定顺序必须严格一致，否则结果会发生错位。
