ADO.NET 2.0

SQLSaturday - SQL Server Data Access Tips and Techniques with David Hayden - Tampa Florida

Dave Hayden — Sun, 10 Feb 2008 12:07:00 GMT

SQLSaturday - SQL Server Data Access Tips and Techniques with David Hayden - Tampa Florida

I will be presenting at SQLSaturday in Tampa, Florida on Saturday, February 16, 2008.

Here is the abstract:

SQL Server Data Access Tips and Techniques

You have optimized and tuned your SQL Server Database and now you need to access the data from your application. Learn and explore the variety of ways you can access the data using ADO.NET, the Data Access Application Block, LINQ To SQL, ADO.NET Entity Framework, ADO.NET Data Services, and the ASP.NET 3.5 Dynamic Data Framework. In this session we will walk-thru and build several examples for each technique as well as discuss tips, strengths, and weaknesses. Come with your questions and explore the wonderful world of data access to SQL Server!

We only have an hour, so I will be prepared to discuss and demo:

ADO.NET 2.0
Enterprise Library Data Access Application Block
LINQ To SQL
ADO.NET Entity Framework
ADO.NET Data Services
ASP.NET Dynamic Data Websites

This is subject to change, of course, but I thought I would break the presentation into thirds:

20 minutes: ADO.NET and DAAB
20 minutes: LINQ To SQL and ASP.NET Dynamic Data
20 minutes: ADO.NET Entity Framework and ADO.NET Data Services

This isn't a deep technical session. It's goal is to expose you to data access options from Microsoft that exist today and are coming down the pike. I will be happy to answer more technical questions after the presentation.

See you there!

Author: David Hayden, Florida Web Developer

Site: http://www.davidhayden.com/

Creating Data Access Layer Using DbProviderFactories and DbProviderFactory

Dave Hayden — Mon, 08 Oct 2007 18:00:00 GMT

Creating Data Access Layer Using DbProviderFactories and DbProviderFactory

by David Hayden ( Florida .NET Developer ), Filed: ADO.NET 2.0

I know I have mentioned DbProviderFactories and DbProviderFactory in ADO.NET 2.0 before, but they were new to some developers this weekend so I thought I would reiterate their use in a database agnostic data access layer in your winform and ASP.NET Web Applications.

If you look at the connection string in your App.Config or Web.Config:

<add
    name="ConnectionString"
    connectionString="server=.;Initial Catalog=Northwind;..."
    providerName="System.Data.SqlClient"
/>

you will notice the providerName Property, which represents the unique name for the .NET Framework data provider used to connect to an underlying data source.

In this case we are connecting to SQL Server, but we don't really need to know that. We can use that providerName to create various connection, command, and other database classes without knowing what type of database we are connecting to by using the DbProviderFactories and DbProviderFactory Classes.

First, let's get the actual connectionString and providerName that make up the database we are connecting to using System.Configuration.ConfigurationManager:

string connectionString =
    ConfigurationManager.ConnectionStrings
    ["ConnectionString"].ConnectionString;
    
string providerName = 
    ConfigurationManager.ConnectionStrings
    ["ConnectionString"].ProviderName;

Once we have the providerName, we can create a DbProviderFactory class for the database using the DbProviderFactories Class:

DbProviderFactory provider =
    DbProviderFactories.GetFactory(providerName);

The DbProviderFactory Class exposes several methods that allow us to create classes to access the database:

CreateConnection()
CreateCommand()
CreateParameter()
CreateDataReader()
CreateDataAdapter()

Again, keep in mind that it does not matter what database we are using at this point - could be SQL Server, Oracle, Microsoft Access, DB2, Firebird, etc. Pick your poison.

Assuming the database supports stored procedures, we can call a stored procedure in a database agnostic way as follows:

using (DbConnection cn = provider.CreateConnection())
{
    cn.ConnectionString = connectionString
    
    using (DbCommand command = cn.CreateCommand())
    {
        command.CommandText = "GetAllCustomers";
        command.CommandType = CommandType.StoredProcedure;

        cn.Open();
        
        using (DbDataReader dr = command.ExecuteReader())
        {
            // Do Something...
        }
    }
}

This is an awesome way to target multiple database with your application.

Don't forget you can do some really cool stored procedure parameter discovery as well:

SqlCommandBuilder.DeriveParameters - Get Parameter Information for a Stored Procedure - ADO.NET Tutorials

All good O/R Mappers and Code Generators for the Data Access Layer handle all of this data access layer database agnostic code for you, but it is still good to know what is happening behind the scenes.

Hope this helps!

Similar ADO.NET Tutorials

by David Hayden ( Florida .NET Developer ), Filed: ADO.NET 2.0

ADO.NET Entity Framework - When To Use It vs. Linq to SQL

Dave Hayden — Sun, 29 Apr 2007 23:30:00 GMT

ADO.NET Entity Framework - When To Use It

by David Hayden ( Florida ASP.NET C# SQL Server Developer )

I mentioned earlier that the ADO.NET Entity Framework was Cut From .NET 3.5 and Visual Studio Orcas and we will have to wait until the first half of 2008 to see a release. In the meantime there is Linq to SQL which I have played with quite a bit and enjoy for O/R Mapping. I showed a trivial example of it not too long ago:

Linq to SQL Example Tutorial - Visual Studio ORCAS March 2007 CTP - ASP.NET

Right after the announcement that the ADO.NET Entity Framework was cut from .NET 3.5, the data access team at Microsoft came out with their strategy for data access that is worth reading here.

I really liked the part that discusses when to use the ADO.NET Entity Framework which I cut and pasted below. Most of it is about the ability to define Client Views on existing database schemas so that you can work with the data logically in the client application as opposed to being limited by the database schema. This is a great feature and one I was really looking forward to.

Anyway, here is when to use the ADO Entity Framework according to Microsoft:

“If you are writing an application that requires any of the following features, you should use the ADO.NET Entity Framework:

The ability to define more flexible mapping to existing relational schema, for example:

Mapping a single class to multiple tables
Mapping to different types of inheritance
Directly Modeling Many to Many relationships
Mapping to an arbitrary query against the store

The ability to query relational stores other than the Microsoft SQL Server family of products.
The ability to share a model across Replication, Reporting Services, BI, Integration Services, etc.
A full textual query language
The ability to query a conceptual model without materializing results as objects”

In the post mentioned above, Linq to SQL is portrayed as more of a rapid development approach for simple projects where the database schema is the domain model and you are using SQL Server. Fair enough. I need that, too :)

Source: David Hayden ( Florida ASP.NET C# SQL Server Developer )

ADO.NET Entity Framework Cut From .NET 3.5 and Visual Studio Orcas

Dave Hayden — Sun, 29 Apr 2007 10:31:00 GMT

ADO.NET Entity Framework Cut From .NET 3.5 and Visual Studio Orcas

by David Hayden ( Sarasota Web Design )

The recent announcement about the ADO.NET Entity Framework being cut from .NET 3.5 and Visual Studio Orcas and instead being shipped during the first half of 2008 has me bewildered this morning. Frans speculates on the decision. I am just disappointed with Microsoft's abililty to deliver solutions as promised, on-time, and with timely maintenance releases and service packs.

News Feed: David Hayden ( Sarasota Web Design )

Reading Connection Strings in Web.Config and App.Config and Enterprise Library DAAB Settings

Dave Hayden — Thu, 22 Feb 2007 20:31:00 GMT

Reading Connection Strings in Web.Config and App.Config and Enterprise Library DAAB Settings

by David Hayden ( Sarasota Web Design ), Filed: ADO.NET 2.0, Enterprise Library

Someone asked a question in the forums about how to list all the connection strings located in the app.config or web.config so he could populate a control that would allow the user to choose the active connection at run-time. The person also was using the Enterprise Library Data Access Application Block and wanted to know how to find the name of the default connection string.

Both good questions. Let's start with the easy one first.

Reading Default Connection String Name in DAAB Configuration Settings

It is very easy to read the default connection string name used by the Enterprise Library Data Access Application Block. There are many ways to do it, but this is the simplest in my opinion if you use the application's web.config or app.config file to store your DAAB Settings:

DatabaseSettings settings = 
  DatabaseSettings.GetDatabaseSettings
       (new SystemConfigurationSource());

string defaultConnectionStringName =
        settings.DefaultDatabase;

There is a DatabaseSettings Class that you can call GetDatabaseSettings on to get the name of the default connection string. Pass it the IConfigurationSource where the settings are located. Use SystemConfigurationSource for the application's app.config or web.config.

Reading All Connection Strings in App.Config or Web.Config

Actually, reading all the connection strings in the app.config or web.config is pretty easy now that we have the wonderful System.Configuration Namespace and its rich functionality. The code is pretty straight forward. We can read all the connection strings as well as each name, provider, etc:

ConnectionStringSettingsCollection connectionStrings =
                    ConfigurationManager.ConnectionStrings;

foreach (ConnectionStringSettings connection in connectionStrings)
{
    string connectionStringName = connection.Name;
    string connectionString = connection.ConnectionString;
    string providerName = connection.ProviderName;

    Debug.Print(connectionStringName);
}

Rather than just printing the connection string name to the output window, you could of course populate a control and allow the user to select one.

Based on the name of the connection string the user selects, you can use the Enterprise Library DAAB to access the database:

Database database =
   DatabaseFactory.CreateDatabase(connectionStringName);

If you don't want to use the DAAB, no problem. Use the DbProviderFactory to give you similar database agnostic code ( albeit not as easy to use as the DAAB ) :

DbProviderFactory factory =
          DbProviderFactories.GetFactory(providerName);
using (DbConnection conn = factory.CreateConnection())
{
    conn.ConnectionString = connectionString;

    // ...
}

Fun stuff to play with.

Conclusion

Hope this helps :)

Source: David Hayden ( Sarasota Web Design )

Filed: ADO.NET 2.0, Enterprise Library

Using Enterprise Library DAAB and Microsoft Access 2007 via ODBC and OLEDB - Connection Strings and ADO.NET

Dave Hayden — Sun, 28 Jan 2007 12:16:00 GMT

The Enterprise Library Data Access Application Block can connect to any database that has a .NET Data Provider. One of the common questions is - “Does Enterprise Library support Microsoft Access?“ The answer is yes! You can use OLEDB or ODBC to connect to the Microsoft Access Database using the Data Access Application Block. In this article I show both ways...

Caching the Stored Procedure Parameters Discovered Using SqlCommandBuilder.DeriveParameters

Dave Hayden — Fri, 03 Nov 2006 15:43:00 GMT

Caching the Stored Procedure Parameters Discovered Using SqlCommandBuilder.DeriveParameters

by David Hayden ( Florida .NET Developer )

Filed: ADO.NET Tutorials and Examples

A couple days ago I talked about a DatabaseHelper Library of mine that mimics the functionality in the Enterprise Library 2.0 Data Access Application Block. To implement the following methods in the DatabaseHelper Library that are in the DAAB:

int ExecuteNonQuery(string storedProcedureName,
           params object[] parameterValues);
IDataReader ExecuteReader(string storedProcedureName,
           params object[] parameterValues);
object ExecuteScalar(string storedProcedureName,
           params object[] parameterValues);                
DataSet ExecuteDataSet(string storedProcedureName,
           params object[] parameterValues);

I took advantage of the SqlCommandBuilder.DeriveParameters method that discovers the parameters on stored procedures. You can read the following article for more information: SqlCommandBuilder.DeriveParameters - Get Parameter Information for a Stored Procedure - ADO.NET Tutorials

Earlier this morning I took a few minutes to add a parameter cache to help with performance when using the parameter discovery functionality. I didn't want to do it, because it creates additional complexity as well as opens up thread safety issues on a library that wasn't meant for performance critical applications, but I figured what the heck :)

ParameterCache Class

I outsourced the caching of parameters to a separate caching service - ParameterCache Class. It is nothing but a thread-safe wrapper around a Dictionary Class. Enterprise Library 2.0 DAAB uses a Hashtable, but that was done before generics, etc. I won't bore you with the whole class, but the partial draft cut looks like this:

public class ParameterCache : IParameterCache
{
    private Dictionary<string, DbParameter[]> dictionary =
                    new Dictionary<string, DbParameter[]>();
    private object syncLock = new object();
    
    public bool ContainsParameters(string connectionString,
                                 string storedProcedureName)
    {
        return dictionary.ContainsKey(
          GetCacheKey(connectionString, storedProcedureName));
    }
    
    public DbParameter[]
        GetParameters(string connectionString,
                                 string storedProcedure)
    {
        return CopyParameterArray(
           dictionary[GetCacheKey(connectionString,
                                   storedProcedure)]);
    }
    
    public void AddParameters(string connectionString,
                   string storedProcedureName,
                   DbParameterCollection parameterCollection)
    {
        if (!ContainsParameters(connectionString,
                                  storedProcedureName))
        {
            lock(syncLock)
            {
                if (!ContainsParameters(connectionString,
                                         storedProcedureName))
                {
                string cacheKey = GetCacheKey(connectionString,
                                          storedProcedureName);
                  DbParameter[] parameters =
                        GetParameterArray(parameterCollection);
                    
                    dictionary.Add(cacheKey, parameters);
                }
            }
        }
    }
}

All I am doing is delegating most of the work to the Dictionary Class. I added a little double-check locking on adding parameters for thread safety, but I have to make sure this is indeed thread safe by doing some testing. Thread safety really becomes an issue when enumerating a Dictionary Class, but we never do that.

Using the Parameter Cache

After a bit of refactoring, the code that I mentioned in the previous article has been cut down to this:

public IDataReader ExecuteReader(string storedProcedureName,
                                 params object[] parameters)
{
    SqlCommand command =
             GetStoredProcCommand(storedProcedureName)
                                             as SqlCommand;

    DiscoverParameters(command);

    SetParameterValues(command, parameters);

    return ExecuteReader(command);
}

I need to add some argument checking, etc., but that is the gist.

The DiscoverParameters Method now checks the cache to see if the parameters are there before making a roundtrip to the database using SqlCommandBuilder.DeriveParameters.

public void DiscoverParameters(DbCommand command)
{
    if (_cache.ContainsParameters(_connectionString,
                          command.CommandText))
    {
        DbParameter[] parameters = _cache.GetParameters
                 (_connectionString, command.CommandText);
        command.Parameters.AddRange(parameters);
    }
    else
    {
        using (SqlConnection connection =
                     CreateConnection() as SqlConnection)
        {
            command.Connection = connection;
            connection.Open();
            SqlCommandBuilder.DeriveParameters(command
                                          as SqlCommand);
        }

        _cache.AddParameters(_connectionString,
                    command.CommandText, command.Parameters);
    }
}

Conclusion

Not bad for about an hour this morning. Unit and integration tests are passing, but I need to create ones that assure thread safety :)

by David Hayden ( Florida .NET Developer )

Filed: ADO.NET Tutorials and Examples

SqlCommandBuilder.DeriveParameters - Get Parameter Information for a Stored Procedure - ADO.NET Tutorials

Dave Hayden — Wed, 01 Nov 2006 15:36:00 GMT

SqlCommandBuilder.DeriveParameters - Get Parameter Information for a Stored Procedure - ADO.NET Tutorials

by David Hayden ( ASP.NET C# Sql Server Developer )

Filed: ADO.NET Tutorials

Last night I was updating a DatabaseHelper Library that I use for small .NET consulting projects. It shares the same interface as Enterprise Library 2.0 DAAB, but without all the bulk. It is a “same taste, less filling” kind of library optimized for Sql Server Database Access that can easily be replaced by the Data Access Appliction Block with basically no code changes should the need arise.

There are a few methods I hadn't got around to implementing yet since I rarely use them. One is the family of method overloads that take an object array of parameter values as such:

IDataReader ExecuteReader(string storedProcedureName,
                params object[] parameterValues)

The idea here is that you want to call a stored procedure that takes some parameters, but you want the convenience of just passing in an object array of parameter values as opposed to creating all the parameters manually. The developer is “asking” the library to “discover“ the proper parameters and assign the values accordingly.

The main reason I don't normally use this overload is because it requires an extra roundtrip to the database by the library to discover the parameters. It is convenient, but not as optimized performance-wise. As an added level of complexity, the DAAB has a parameter cache to cache the parameters discovered on the first call to the stored procedure. This saves you the performance hit on subsequent calls, but just adds complexity to the library as well as cache management.

SqlCommandBuilder.DeriveParameters

The magical bit of code that discovers stored procedure parameters in the background is the SqlCommandBuilder.DeriveParameters method. You call the method passing in an SqlCommand object as such:

SqlCommandBuilder.DeriveParameters(command);

and it will populate the SqlParametersCollection on the command for you. Only thing you need to do is populate the input parameters with their appropriate values and execute the query.

SqlCommandBuilder.DeriveParameters Example

Here is a first cut at what the code might look like to use this functionality:

private IDataReader ExecuteReader(string storedProcedureName,
                       params object[] parameterValues)
{
    SqlConnection connection = null;
    
    try
    {
        connection = CreateConnection();

        // Create Command
        SqlCommand command = connection.CreateCommand();
        command.CommandType = CommandType.StoredProcedure;
        command.CommandText = storedProcedureName;
        
        // Open Connection
        connection.Open();
        
        // Discover Parameters for Stored Procedure
        // Populate command.Parameters Collection.
        // Causes Rountrip to Database.
        SqlCommandBuilder.DeriveParameters(command);

        // Initialize Index of parameterValues Array
        int index = 0;
        
        // Populate the Input Parameters With Values Provided        
        foreach (SqlParameter parameter in command.Parameters)
        {
            if (parameter.Direction == ParameterDirection.Input ||
                 parameter.Direction == ParameterDirection.
                                             InputOutput)
            {
                parameter.Value = parameterValues[index];
                index++;
            }
        }

        return command.ExecuteReader(CommandBehavior.
                                       CloseConnection);
    }
    catch
    {
        if (connection != null && connection.State
                                == ConnectionState.Open)
            connection.Close();
        throw;
    }
}

You could add some caching here of the parameters so the parameter discovery only happens once.

The client code calling the method may look like:

// Call GetBlogsByBlogId Stored Procedure
// BlogId = 1
using (IDataReader dr = ExecuteReader("GetBlogByBlogId", 1))
{
    Blog blog = null;
    
    if (dr.Read())
    {
        BlogFactory factory = new BlogFactory();
        blog = factory.Construct(dr);
    }
}

Conclusion

Next time you want to find the parameters used by a stored procedure, check out the use of SqlCommandBuilder.DeriveParameters.

Source: David Hayden ( ASP.NET C# Sql Server Developer )

Filed: ADO.NET Tutorials

Get List of Tables in an Access Database - ADO.NET Tutorials

Dave Hayden — Sun, 01 Oct 2006 18:32:00 GMT

Get List of Tables in an Access Database - ADO.NET Tutorials

by David Hayden ( ASP.NET C# SQL Server Developer ) Filed: ADO.NET Tutorials

A question came up in the MSDN Forums regarding how to get a list of tables in an Access Database. I have a couple tutorials on how to do this in SQL Server, but I never tackled the challenge using Microsoft Access:

I thought I wrote an example using SQL Server Management Objects ( SMO ), but I guess not. I will have to add that to the list :)

The key is the use of GetSchema, which is new to ADO.NET 2.0. Here is an article I wrote introducing GetSchema:

GetSchema - DbConnection.GetSchema in ADO.NET 2.0 - Retrieve Databases Tables Columns Views etc. from Database Connection

Here is the code to get a list of tables in an Access Database, short and sweet:

// Microsoft Access provider factory
DbProviderFactory factory =
    DbProviderFactories.GetFactory("System.Data.OleDb");

DataTable userTables = null;

using (DbConnection connection =
            factory.CreateConnection())
{
    // c:\test\test.mdb
    connection.ConnectionString = "Provider=Microsoft
        .Jet.OLEDB.4.0;Data Source=c:\\test\\test.mdb";
    
    // We only want user tables, not system tables
    string[] restrictions = new string[4];
    restrictions[3] = "Table";
    
    connection.Open();
    
    // Get list of user tables
    userTables =
        connection.GetSchema("Tables", restrictions);
}

// Add list of table names to listBox
for (int i=0; i < userTables.Rows.Count; i++)
    listBox1.Items.Add(userTables.Rows[i][2].ToString());

The userTables DataTable looks like this using the DataSet Visualizer:

Pretty simple once you get to appreciate GetSchema. Hope this helps.

Written By: David Hayden ( ASP.NET C# SQL Server Developer )

Filed: ADO.NET Tutorials

Enterprise Library 2.0 DAAB - Retrieving PK and Timestamp When Inserting New Record

Dave Hayden — Wed, 26 Jul 2006 13:53:00 GMT

I was answering a number of questions on the Enterprise Library 2.0 DAAB Message Board today, and this one was worth a blog post since the question comes up a lot in various forums. Although I am showing this using Enterprise Library 2.0 DAAB, the answer applies to SqlClient as well. Let's say you're inserting a new customer row in the Customers Table and you want to retrieve the PK and Timestap ( Rowversion ) of the row..