Showing posts with label Microsoft Data Access Block. Show all posts
Showing posts with label Microsoft Data Access Block. Show all posts

Tuesday, 29 May 2007

Microsoft released Enterprise Libraries 3.1 - May 2007

Microsoft have release Enterprise Library 3.1 which contains a few updates from the previous January 06 version. I've installed it and I much prefer the cleaner start menu options which just take you to the source folder and let you browse away.
Note: If you already have the Enterprise Library 3.0 installed, you must uninstall it before installing the Enterprise Library 3.1. However, you can install the Enterprise Library 3.0 or the Enterprise Library 3.1 when 2.0 is already installed.

The patterns & practices Enterprise Library is a library of application blocks designed to assist developers with common enterprise development challenges. Application blocks are a type of guidance, provided as source code that can be used "as is," extended, or modified by developers to use on enterprise development projects. This release of Enterprise Library includes application blocks for Caching, Cryptography, Data Access, Exception Handling, Logging, Policy Injection, Security and Validation.

Thursday, 17 May 2007

How parameters are processed in the Microsoft Data Access Block

I've been using the Microsoft Data Access Block for a while and only came across something that isn't clear in its operation and can have some very nasty side effects. Inside the SqlHelper class, there is a method called AssignParameterValues which "...assigns an array of values to an array of SqlParameters". This sounds good although it's not clear that it does this using index position rather than matching on the parameter name. Therefore, if you create a procedure with 2 parameters both varchars, the order in which you pass the command parameters array to the method is the order in which the SqlHelper executes them against the server. This defeats the purpose of naming your parameters in your code. For example, if you create a method to build your parameters like this:

private static SqlParameter[] CreateMyParameters(string firstname, string surname)
{
SqlParameter firstnameParameter = new SqlParameter("@Firstname", SqlDbType.Varchar);
firstnameParameter.Value = firstname;

SqlParameter surnameParameter = new SqlParameter("@Surname", SqlDbType.Varchar);
surnameParameter.Value = surname;

new SqlParameter[] { firstnameParameter, surnameParameter };
}


then use the

public static int ExecuteNonQuery(SqlConnection connection, string spName, params object[] parameterValues)

method, your nicely named parameters array is attached to the command object based on their position on the array position and not their names. The method that does this is called AssignParameterValues.
However, the same problem does not happen when you use the method

public static SqlDataReader ExecuteReader(SqlConnection connection, CommandType commandType, string commandText, params SqlParameter[] commandParameters)


The ExecuteReader just attaches the parameters as you created directly to the command object and therefore the parameter names are preserved.

This makes naming the parameters pretty useless for nonquery or scalar operations. It would be nice to see this method modified to use the parameter names which would take advantage of the some of the methods in the SqlHelperParameterCache class.