Call oracle Stored Procedure with EF fail

Question

I have an oracle store procedure which take 2 strings and a date in input parametter and which give a ref cursor as output :

CREATE OR REPLACE PROCEDURE SCHEMA.MYPROSTO (
   pPl    IN     VARCHAR2, -- Comma (;) separated
   pTy    IN     VARCHAR2,-- Comma (;) separated
   pDate     IN     mytable.mydate%TYPE,
   pCursor      OUT sys_refcursor)
IS
   .....
   sSQL      VARCHAR2 (3000);
BEGIN

   -- making SQL Order
   sSQL := 'SELECT TO_CHAR (v.date_c........

   ......


   OPEN pCursor FOR sSQL;

END MYPROSTO;

The output cursor return a set of 3 string cells rows.

I imported this stored procedure in my entity framework model, with this in the .config file :

<oracle.manageddataaccess.client>
<version number="*">
  <implicitRefCursor>
    <storedProcedure schema="SCHEMA" name="MYPROSTO">
      <refCursor name="PCURSOR">
        <bindInfo mode="Output"/>
        <metadata columnOrdinal="0" columnName="YEAR" providerType="Varchar2" allowDBNull="true" nativeDataType="Varchar2"/>
        <metadata columnOrdinal="1" columnName="MONTH" providerType="Varchar2" allowDBNull="true" nativeDataType="Varchar2"/>
        <metadata columnOrdinal="2" columnName="COUNT" providerType="Varchar2" allowDBNull="true" nativeDataType="Varchar2"/>
      </refCursor>
    </storedProcedure>
  </implicitRefCursor>
</version>
</oracle.manageddataaccess.client>

The function import wizzard created a result object and generated an access function :

public virtual ObjectResult<MYPROSTO_Result> MYPROSTO (string pPL, string pTY, Nullable<System.DateTime> pDATE)
{
    var pPLParameter = pPL!= null ?
        new ObjectParameter("PPL", pPL) :
        new ObjectParameter("PPL", typeof(string));

    var pTYParameter = pTY!= null ?
        new ObjectParameter("PTY", pTY) :
        new ObjectParameter("PTY", typeof(string));

    var pDATEParameter = pDATE.HasValue ?
        new ObjectParameter("PDATE", pDATE) :
        new ObjectParameter("PDATE", typeof(System.DateTime));

    return ((IObjectContextAdapter)this).ObjectContext.ExecuteFunction<MYPROSTO_Result>("MYPROSTO", pPLParameter, pTYParameter, pDATEParameter);
}

However, the call to this function raise an exception ( System.Data.Entity.Core.EntityCommandExecutionException ) on the last line :

ORA-06550: Ligne 1, colonne 8 : PLS-00306: wrong number or types of arguments in call to 'MYPROSTO'
ORA-06550: Ligne 1, colonne 8 : PL/SQL: Statement ignored

I don't see why it fail

Answer 1

There appears to be several problems:

• Sending a varchar(2) into a date field
• The name of a parameter "pTY" versus "pType"
• The name of a parameter "pPL" versus "pPlant"
• The name of a parameter "PPLT" versus "PPL"

Answer 2

What about return parameter. It is "mapped" ok? DoubleCheck

Answer 3

Surely the answer is clear in the error message:

"wrong number or types of arguments in call to 'MYPROSTO'"

Your procedure expects 4 parameters but you're only passing 3. You need an output variable for the refcursor.

Answer 4

I had the same thing happen to me and FINALLY solved it. I was using the oracle.manageddataaccess.client, like you, and had my .NET solution divided into a Presentation Project, WebAPI Project, and Data Access Project. My app.config in the Data Access Project had the correct ImplicitRefCursor section with the cursor definition and metadata like you have, but I forgot to also copy it into my web.config of my WebAPI project. Once I did that, my "wrong number or types of arguments" error went away. Hope that helps. (I just copied the whole oracle.manageddataaccess.client section.)

Also, if you generated that whole ImplicitRefCursor section by hand, I discovered a much easier and reliable way to do that. From the .NET Server Explorer, connect to your database, find your stored procedure, right-click on it and RUN. Then OK. It will bring up a list of IN and OUT parameters, including the cursor. If you click on Show Config button, it will show you what needs to be in your EF app.config. And the AddConfig button will add it for you. That helps to avoid mistakes.