This topic has not yet been rated - Rate this topic

SqlCommandBuilder.DeriveParameters Method

Retrieves parameter information from the stored procedure specified in the SqlCommand and populates the Parameters collection of the specified SqlCommand object.

Namespace:  System.Data.SqlClient
Assembly:  System.Data (in System.Data.dll)
public static void DeriveParameters(
	SqlCommand command
)

Parameters

command
Type: System.Data.SqlClient.SqlCommand
The SqlCommand referencing the stored procedure from which the parameter information is to be derived. The derived parameters are added to the Parameters collection of the SqlCommand.
Exception Condition
InvalidOperationException

The command text is not a valid stored procedure name.

DeriveParameters overwrites any existing parameter information for the SqlDbCommand.

DeriveParameters requires an additional call to the database to obtain the information. If the parameter information is known in advance, it is more efficient to populate the parameters collection by setting the information explicitly.

You can only use DeriveParameters with stored procedures. You cannot use DeriveParameters with extended stored procedures. You cannot use DeriveParameters to populate the SqlParameterCollection with arbitrary Transact-SQL statements, such as a parameterized SELECT statement.

For more information, see Configuring Parameters and Parameter Data Types (ADO.NET).

.NET Framework

Supported in: 4, 3.5, 3.0, 2.0, 1.1, 1.0

.NET Framework Client Profile

Supported in: 4, 3.5 SP1

Windows 7, Windows Vista SP1 or later, Windows XP SP3, Windows XP SP2 x64 Edition, Windows Server 2008 (Server Core not supported), Windows Server 2008 R2 (Server Core supported with SP1 or later), Windows Server 2003 SP2

The .NET Framework does not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.
Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
Beware of parameters with user-defined types
Given the following SQL:
create type TestType varchar(50)
go

create procedure my_test_proc
               ( @UserName TestType,
@EditDate dtetime )
as

...

If the login that DeriveParameters is run under does not have permission to access the TestType type, no error will be thrown - the method will return successfully, but the SqlCommand.Parameters collection will not contain the @UserName parameter.


Table valued parameters not typed correctly
If you use this on a table-valued parameter, you will recieve this error:

The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Table-valued parameter 1 ("@paramname"), row 0, column 0: Data type 0xF3 (user-defined table type) has a non-zero length database name specified.  Database name is not allowed with a table-valued parameter, only schema name and type name are valid.

The problem is caused because TypeName is set to "database.schema.typename" rather than "schema.typename" as is expected.

Here is my solution:

        internal void DeriveParameters(SqlCommand command)
        {
            SqlCommandBuilder.DeriveParameters(command);

            foreach(SqlParameter param in command.Parameters)
            {
                if(param.SqlDbType != SqlDbType.Structured)
                    continue;

                // param.TypeName will be database.schema.typename
                string typeName = param.TypeName;

                // Trim off the database name to get schema.typename
                typeName = typeName.Substring(typeName.IndexOf(".") + 1);

                // If Microsoft fix this in a future release and only return
                // schema.typename, we would end up with just the typename (no dot)
                // So only change the TypeName if we still have a dot in our text
                if(typeName.Contains("."))
                    param.TypeName = typeName;
            }
        }

This method is not supported to determine parameters of SQL CLR Procedures
When attempting to derive the parameter list of a SQL CLR procedure, and exception will result which states:
"The stored procedure '<ProcedureName>' doesn't exist"

This exception message is misleading. A workaround for this is to "wrap" the SQL CLR procedure in a normal T-SQL Stored procedure call to allow parameters to be derived.

For further information about this issue, refer to the following support case ...