adoADO.NET 2.0 Feature Matrix
Bob Beauchemin
DevelopMentor
July 2004
Applies to:
Microsoft ADO.NET 2.0
Microsoft SQL Server 2005
Summary: ADO.NET 2.0 includes a new base-class provider model, features for all providers, and
changes to System.Data.SqlClient. Get an overview of these new features, examples of their use, and a
chart of which features are provider-neutral and SqlClient-specific. (14 printed pages)
Contents
The Base-Class-Based Provider Model
Connection Pooling Enhancements
Asynchronous Commands
Bulk Import
Provider Statistics
AttachDbFileName
SQL Server 2005-Specific Features in SqlClient
Conclusion
ADO.NET 2.0 comes with a plethora of new features. This includes a new base-class–based provider
model and features that all providers can take advantage of, as well as changes that are specific to
System.Data.SqlClient. Because the .NET Framework 2.0 is being released in conjunction with SQL
Server 2005, some of these features require SQL Server 2005 to be usable. This article is meant to serve
as an overview and roadmap of the new features, give examples of their use, and includes a chart of
which features are provider-neutral and which are SqlClient-specific. In future articles in this series, I'll
be going over some of the features in greater detail. In addition, there are many new features of the
DataSet and friends; these will be covered in future articles.
The Base-Class-Based Provider Model
In ADO.NET 1.0 and 1.1, provider writers implemented a series of provider-specific classes. Generic
coding was possible based on the fact that each of the classes implemented a generic interface. As an
example, System.Data.SqlClient contains the class SqlConnection and this class implements
IDbConnection. System.Data.OracleClient contains the class OracleConnection, which also
implements IDbConnection. The provider-specific classes could implement data-source–specific
properties and methods, e.g., SqlConnection implements the Database property and the
ChangeDatabase method. OracleConnection does not, because the Oracle database does not have the
concept of multiple "databases" (these are known as catalogs in ANSI SQL) per database instance. The
new provider model in ADO.NET 2.0 is based on a series of base classes in System.Data.Common.
These provide a basic implementation of common functionality and, of course, each of the base classes
implements the still-required generic interface for backward compatibility. Provider writers can choose to
use the base classes or support the interfaces.
There were two exceptions to the interface model in previous versions, the
DataAdapter/DbDataAdapter and CommandBuilder. The CommandBuilder class provides an
automatic implementation of INSERT, UPDATE, and DELETE commands that use the same column-set,
for a simple SELECT command. Extending a CommandBuilder while keeping the base algorithm that it
used to create action statements was not possible because the SqlCommandBuilder was a sealed class.
Although there is still no way to reuse the SqlCommandBuilder parameter parser, there is a
DbCommandBuilder base class in System.Data.Common. There are new features exposed at the
base-class level in these classes, too. The DataAdapter/DbDataAdapter base classes expose mechanisms
for pushing provider-specific types like SQL Server SqlTypes into the DataSet (the
ReturnProviderSpecificTypes property) and for batch updates (StatementType.Batch enumeration
value and UpdateBatchSize property). The DbCommandBuilder common base class includes a property
to indicate concurrency policy choices (the ConflictDetection property).
Provider Factories
One of the complications of the interface-based approach in ADO.NET 1.0 and 1.1 is that you can't call a
constructor on an interface. You must create a concrete instance of a specific class. Previous APIs like
OLE DB and ADO worked around this by overloading the connection string. The connection string
contained the COM PROGID of the provider, and the correct DataSource class was created based on this
PROGID. This was possible because OLE DB DataSource PROGIDs were stored in the registry.
' VB6 ADO code, Connection is an interface (actually it's _Connection)
Dim conn as Connection
' note that the default provider is MSDASQL, the OLE DB provider for ODBC
' this uses the OLE DB provider for SQL Server
conn.ConnectionString = "provider=sqloledb;.." ' other parameters
deleted
conn.Open
ADO.NET 2.0 has a solution for this. Each data provider registers a ProviderFactory