7 The Oracle Data Provider : Using Stored Procedures

Using Stored Procedures
The following sections describe how the Oracle data provider supports specific Oracle features for stored procedures. See “Using Stored Procedures” for more information on how the Oracle data provider uses stored procedures.
Using REF CURSOR Parameters
When executing a stored procedure, the Oracle data provider returns the results from the REF CURSOR as the result set from the stored procedure. No input from the application is required. When you call a stored procedure that returns a REF CURSOR parameter, do not bind an OracleParameter object to the REF CURSOR parameter.
If a stored procedure returns multiple REF CURSORs, the Oracle data provider returns them as multiple result sets in the order of the REF CURSOR parameters in the Create Procedure statement.
See “Ref Cursor Mode” for information on how to specify the way that the data provider processes REF CURSORs.
Supporting the PL/SQL Associative Array
The Oracle data provider supports access to stored procedures and stored functions that return arguments of type PL/SQL Associative Array or of type Table.
The Oracle data provider uses the OracleParameter object to support the PL/SQL Associative Array type (see “OracleParameter Class”). Users can supply the list of values as a .NET Array object. If the stored procedure has input arguments of this type, the list is supplied before executing; if the stored procedure or function has input/output arguments, the list is supplied after executing.
To bind a parameter of this type, the application must set the OracleParameter object with the following values:
Using Named Parameters
Using named parameters in stored procedures lets you bind parameters by name. This means that you do not have to enter the parameters in order. To optimize interoperability, you can use standardized parameter markers, which is the default behavior for the Oracle data provider. Alternatively, you can use provider-specific parameter markers and binding behavior with your existing applications.
Using Standardized Parameter Markers
When using named parameters in stored procedures with the Oracle data provider, you do not need to use the native style parameter mark in your SQL statement. Instead, you can use ? as the marker.
For example, suppose you have a stored procedure with the following parameters:
CREATE PROCEDURE MYPROC (p0 IN INTEGER, p1 IN CHAR, p3 IN
   CHAR DEFAULT 'ADO.NET')
When the BindByName property is set to True (see “OracleParameter Class”), you can bind the parameters out of order, as shown in the following C# code fragment:
cmd.BindByName = True; // Required to enable this feature
cmd.Parameters.Add(new OracleParameter("p1", "DataDirect"));
cmd.Parameters.Add(new OracleParameter("p0", 8888));
cmd.Parameters.Add(new OracleParameter("p3", "Oracle"));
In this case, the parameter names match the names in the stored procedure definition.
The BindByName property also allows you to use a parameter’s default value. For example, in the procedure definition, the p3 parameter has a default value of ADO.NET. To use that default value, simply omit that parameter from the binding:
cmd.CommandText = "{call MYPROC (?, ?)}";
// Only two ?s used
In this case, you would bind only two parameters on the command:
cmd.BindByName = True; // Required to enable this feature
cmd.Parameters.Add(new OracleParameter("p0", 8888));
cmd.Parameters.Add(new OracleParameter("p1", "DataDirect"));
You can also use CommandType.StoredProcedure to execute the stored procedure:
cmd.CommandType = CommandType.StoredProcedure;
cmd.CommandText = "MYPROC";
cmd.BindByName = True;
cmd.Parameters.Add(new OracleParameter("p1", "DataDirect"));
cmd.Parameters.Add(new OracleParameter("p0", 8888));
Using Native Parameter Markers
You can set the Parameter Mode connection string option to define the behavior of native parameter markers and binding. This allows applications to reuse data provider-specific SQL code and simplifies migration to the DataDirect data provider.