9 The SQL Server Data Provider : Using Stored Procedures

Using Stored Procedures
The SQL Server data provider supports multiple result sets and return codes from SQL Server stored procedures when parameters are bound as return codes. The stored procedures must take an argument list.
The SQL Server data provider supports calling stored procedures defined in .NET Managed Code Assemblies.
Using Stored Procedures in a Batch
Batch support for the DataAdapter was released as an integrated component of the ADO.NET 2.0 API, eliminating the need to update each row, one at a time, for each Update call. You can set the UpdateBatchSize property to control the size of each batch update (see “SQLServerParameter Class” for more information.
If a stored procedure call is part of the batch and the BindByName connection string option is set to Native Provider Mode, the SQL Server data provider issues each stored procedure call as a single command. This avoids possible naming collisions with named parameters, if the parameter names repeat.
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. An application can use named parameters by specifying the Name property of a parameter as @xxx where xxx can be any character. The name specified must match the name given in the Create Procedure statement for the parameter. To optimize interoperability, you can use standardized parameter markers, which is the default behavior for the SQL Server data provider.
When using named parameters, all parameters in the stored procedure must be named. However, if the stored procedure was created with default values for some or all of the parameters, the application does not need to specify SQLServerParameter objects for any parameters for which it wants to use the default values.
Alternatively, you can use provider-specific parameter markers and binding behavior with your existing applications. The Parameter Mode connection string option specifies the behavior of native parameter markers and binding. This allows applications to reuse provider-specific SQL code and simplifies migration to the DataDirect data providers. SQL Server provides named parameter support if the @ tag is used in the parameter name.
Using Standardized Parameter Markers
When using named parameters in stored procedures with the SQL Server 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 “SQLServerParameter 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 SQLServerParameter("p1", "DataDirect"));
cmd.Parameters.Add(new SQLServerParameter("p0", 8888));
cmd.Parameters.Add(new SQLServerParameter("p3", "SQLServer"));
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 SQLServerParameter("p0", 8888));
cmd.Parameters.Add(new SQLServerParameter("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 SQLServerParameter("p1", "DataDirect"));
cmd.Parameters.Add(new SQLServerParameter("p0", 8888));