Oracle存储过程输出参数值

Question

One of our clients inherited a fairly large PMS based on asp.net/oracle. Unfortunately my knowledge of oracle is minimal and I'm having a few issues:-

Original system was based around Oracle 9 and is using the System.Data.OracleClient driver from MS. The new client has opted for an Oracle 12c appliance box and the database was transferred successfully but some of the existing stored procedures are problematic - for instance

PROCEDURE IS_PROJECT_LEADER(A_PROJ_ID NUMBER, A_ACCOUNT_ID VARCHAR2, A_SUCCESS OUT VARCHAR2)
IS
    v_COUNT NUMBER;
BEGIN
    --Check if Project Leader, or in the Project Leader Group
    SELECT  COUNT(*)
    INTO    v_COUNT
    FROM    PROJ_ACCOUNT
    WHERE   PROJ_ID = A_PROJ_ID
    AND     ACCOUNT_ID = A_ACCOUNT_ID
    AND     (SYS_ROLE_ID = 3 OR IS_PL_GROUP = 'Y');

    IF v_COUNT > 0 THEN
        A_SUCCESS := 'Y';
    ELSE
        A_SUCCESS := 'N';
    END IF;
END;

The parameters are initialised using this code - not sure if this is correct or not in the oracle world?

while (rdr.Read())
{
  prm = new OracleParameter();
  prm.ParameterName = rdr["ARGUMENT_NAME"].ToString();
  switch (rdr["DATA_TYPE"].ToString())
  {
    case "NUMBER":
      prm.OracleType = OracleType.Number;
      break;
    case "VARCHAR2":
      prm.OracleType = OracleType.VarChar;
      if (rdr["IN_OUT"].ToString() == "OUT"
        || rdr["IN_OUT"].ToString() == "IN/OUT")
      {
        prm.Size = 4000;
      }
      break;
    case "DATE":
      prm.OracleType = OracleType.DateTime;
      break;
    case "BLOB":
      prm.OracleType = OracleType.Blob;
      break;
      case "CLOB":
         prm.OracleType = OracleType.Clob;
         break;

        }
  switch (rdr["IN_OUT"].ToString())
  {
    case "IN":
      prm.Direction = ParameterDirection.Input;
      break;
    case "OUT":
      prm.Direction = ParameterDirection.Output;
      break;
    case "IN/OUT":
      prm.Direction = ParameterDirection.InputOutput;
      break;
  }
  prm.Value = System.DBNull.Value;
  cmd.Parameters.Add(prm);
}

The return value of A_SUCCESS in the current system is always an empty string. If I remove the MS OracleClient and use the latest Oracle ODP.net drivers then the required string value is returned...or if I change the data type and return type of A_SUCCESS to CHAR then everything works. There are plans to move to the ODP client as recommended by MS - however the system is fairly large and badly designed so won't be done for months.

Am I right though in thinking this is a driver issue and not some esoteric Oracle functionality that I am unaware of?

Answer 1

I currently work in Oracle 12c/c#.Net. We do use Oracle's ODP driver which we've found to be more successful than Microsoft's driver.

I'm changing the way I'm stating my answer because of the comment. But I don't think I'm that far off. The accepted answer to the thread, Exception while executing stored procedure odp.net , given by MTO was to add the size or length of the varchar2 field to the parameter definition which is what I was trying to say. Even though A_SUCCESS isn't stored in the database, it requires storage to execute within the procedure.

Here's what we know:

1. It worked when you changed the procedure datatype to CHAR.
2. You didn't change the parameter (prm) settings on the c# side which means the calling program used the same settings for VARCHAR2 as it did for CHAR.
3. CHAR has a default length of 1. VARCHAR2's length has to be set.
4. It worked on 9i but not 12c. The way VARCHAR2's are stored changed between 9i and 12c.
5. It works with ODP. This is strange if it's a length issue because ODP also needs the length of VARCHAR2 to be set.

I'd try this:

1. Print the contents of prm for each parameter to see what's actually being set.
2. If A_SUCCESS isn't being set as VARCHAR2, make sure it is and that it has a length or size set.
3. I know it's a long shot but I'd try setting the length of A_SUCCESS in the procedure using a local variable. I suggest it because changing the datatype to CHAR worked.

Answer 2

Thanks for the help. Client decided to jumpstart the conversion to ODP as it seemed the most logical solution. Working as expected.