Microsoft SQL Server 2005 Developer’s Guide- P20 docx

169
CHAPTER
6
Developing Database
Applications with ADO.NET
IN THIS CHAPTER
The ADO.NET Architecture
ADO.NET Namespaces
.NET Data Providers
Core Classes in the ADO.NET System.Data Namespace
Using the .NET Framework Data Provider for SQL Server
Using the SqlConnection Object
Using the SqlCommand Object
Using the SqlDependency Object
Using the SqlDataReader Object
Using the SqlDataAdapter Object
Copyright © 2006 by The McGraw-Hill Companies. Click here for terms of use.
170 Microsoft SQL Server 2005 Developer’s Guide
I
n this chapter, you will see how to develop SQL Server database applications
using Visual Basic and ADO.NET. The first part of the chapter provides you
with an overview of the ADO.NET data access technology. The second part
of this chapter introduces you to the different ADO.NET namespaces and gives you
an overall understanding of the functions of the different classes that compose the
ADO.NET architecture. Finally, the last section of this chapter covers the classes
that are used by the ADO.NET DataSet object. In this part of the chapter, you’ll get
an understanding of DataTable, DataColumn, DataRow, and other classes used by
the new ADO.NET DataSets.
The ADO.NET Architecture
At its essence, ADO.NET is data access middleware that enables the development
of database applications. ADO.NET builds on the platform provided by the .NET

Framework. ADO.NET is built using managed code from the Microsoft .NET
Framework, which means that it enjoys the benefits of the robust .NET execution
time environment. Designed primarily to address the issues of Web and distributed
applications, ADO.NET consists of a set of classes or namespaces within the
.NET Framework that provide data access and management capabilities to .NET
applications.
As a data access framework, ADO.NET has been primarily designed to allow it to
work in the disconnected data access model that is required by n-tiered Web-based
applications. ADO, the direct predecessor of ADO.NET, was primarily designed to
accommodate a two-tiered client/server style of applications, which typically open
a database connection when the application first starts and then hold that connection
open until the application ends. This technique works fine for most intranet-style
applications where the total number of client connections is a known quantity, and
where the state of the application is typically controlled by the application and
therefore is also a known quantity. Although this approach worked well for single-
tier desktop applications and two-tiered client/server-style applications, it ran into
serious limitations for n-tiered Web-style applications. Because the Web is a public
environment, the total number of open connections required by Web applications
isn’t a known quantity. It could vary greatly and quickly: At one minute, an application
may need only a handful of connections, but the need can jump to thousands of
connections just a few minutes later. Keeping open connections in this type of
environment hurts scalability because each connection must go through the overhead
of initializing the connection with the back-end database, plus each open connection
requires system resources to be held open—reducing the resources available for
Chapter 6: Developing Database Applications with ADO.NET 171
other database operations. As ADO evolved, Microsoft added mechanisms such as
disconnected recordsets to help deal with Web-style applications, but these were
never part of ADO’s original design.
Microsoft designed ADO.NET to be able to handle the disconnected computing
scenario required by Web-based applications. This disconnected design enables

ADO.NET to be readily scalable for enterprise applications because an open connection
isn’t maintained between each client system and the database. Instead, when a client
connection is initiated, a connection to the database is briefly opened, the requested
data is retrieved from the database server, and the connection is closed. The client
application then uses the data completely independently from the data store maintained
by the database server. The client application can navigate through its subset of the
data, as well as make changes to the data, and the data remains cached at the client
until the application indicates that it needs to post any changes back to the database
server. At that point, a new connection is briefly opened to the server and all of the
changes made by the client application are posted to the database in an update batch
and the connection is closed.
The core ADO.NET component that enables this disconnected scenario is
the DataSet. The DataSet is essentially a miniature in-memory database that is
maintained independently of the back-end database. Connections to the data source
are opened only to populate the DataSet or to post changes made to the data in the
DataSet back to the database. This disconnected computing scenario minimizes
the system overhead and improves application throughput and scalability. The
in-memory database provided by the ADO.NET DataSet provides many of the
functions that you’ll find in a full-blown database, including support for data
relations, the capability to create views, and support for data constraints, as well
as support for foreign key constraints. However, being an in-memory structure, it
doesn’t provide support for many of the more advanced database features that you
would find in enterprise-level database products like SQL Server. For example, the
DataSet doesn’t support triggers, stored procedures, or user-defined functions.
Support for disconnected Web-based applications was one of Microsoft’s
priorities in the design of ADO.NET; however, that isn’t all that ADO.NET is
capable of. The disconnected model may be appropriate for Web applications, but it
really isn’t the best model for client/server and desktop applications. These types of
applications can perform better and more efficiently when they run in a connected
fashion. To support this connected style of computing, ADO.NET also provides

a DataReader object. The DataReader essentially provides fast forward–only cursor
style of data access that operates in a connected fashion. While the DataSet provides
the basis for disconnected Web applications, the DataReader enables the fast
connected style of data access needed by desktop and client/server applications.
172 Microsoft SQL Server 2005 Developer’s Guide
In this section, you got a high-level overview of the ADO.NET data access
middleware. Here you saw that ADO.NET provides the tools to build applications
that support both disconnected Web applications as well as connected client/server
style applications. In the next section, you’ll get a close look at the different
namespaces that make up the ADO.NET architecture.
ADO.NET Namespaces
ADO.NET is implemented as a set of classes that exist within the .NET Framework.
These ADO.NET classes are grouped together beneath the .NET Framework’s
System.Data namespace. Several important namespaces make up the ADO.NET data
access technology. First, the .NET Data Providers are implemented in the System.
Data.SqlClient, System.Data.OracleClient, System.Data.OleDbClient, and
System.Data.Odbc namespaces. The classes in these four namespaces provide
the underlying database connectivity that’s required by all of the other ADO.NET
objects. The System.Data.SqlClient namespace provides connectivity to SQL
Server 7, SQL Server 2000, and SQL Server 2005 databases. The System.Data.
OracleClient namespace provides connectivity to Oracle 8 and 9 databases. The
System.Data.OleDbClient namespace provides connectivity to SQL Server 6.5 and
earlier databases, as well as Access and Oracle databases. And the System.Data.
Odbc namespace provides connectivity to legacy databases using ODBC drivers.
These classes also provide support for executing commands, retrieving data in a
fast forward-only style of access, and loading ADO.NET DataSets. Next, there are
the classes contained in the System.Data namespace itself. These classes can be
considered the core of the ADO.NET technology, and they provide support for the
new ADO.NET DataSet class and its supporting classes. As you learned earlier in
this chapter, the DataSet is an in-memory database cache that’s designed to be used

in a disconnected fashion. The DataSet consists of a complete collection of tables,
columns, constraints, rows, and relationships, plus appropriately named DataTables,
DataColumns, DataConstraints, DataRows, and DataRelations. You can see an
illustration of the overall ADO.NET architecture in Figure 6-1.
.NET Data Providers
The.NET Data Providers are responsible for connecting your .NET application to
a data source. The .NET Framework comes with four built-in .NET Data Providers.
Each of the .NET Data Providers is maintained in its own namespace within the
.NET Framework.
Chapter 6: Developing Database Applications with ADO.NET 173
Namespaces for the .NET Data Providers
Four .NET Data Providers are delivered with the .NET Framework: the .NET Data
Provider for SQL Server, the .NET Data Provider for Oracle, the .NET Data Provider
for OLE DB, and the .NET Data Provider for ODBC. The .NET Data Provider for
User Interface
WebForms WinForms
DataSet
DataTable
DataColumn
DataConstraint
DataRow
DataRelationCollection
.NET Data Provider
DataReader
DataAdapter
SelectCommand
DeleteCommand
InsertCommand
UpdateCommand
Command

Parameters
Connection
Data Source
Figure 6-1 Overall ADO.NET architecture
174 Microsoft SQL Server 2005 Developer’s Guide
SQL Server is contained in the System.Data.SqlClient namespace. The .NET Data
Provider for Oracle is contained in the System.Data.OracleClient namespace. The
.NET Data Provider for OLE DB is contained in the System.Data.OleDbClient
namespace. And the .NET Data Provider for ODBC is contained in the System.Data.
Odbc namespace.
System.Data.SqlClient
The System.Data.SqlClient is the .NET managed data provider for SQL Server. The
System.Data.SqlClient namespace uses SQL Server’s native TDS (Tabular Data
Stream) protocol to connect to the SQL Server system. Using the native TDS protocol
makes the .NET Data Provider for SQL Server the fastest possible connection between
a client application and SQL Server.
System.Data.OleDb
The System.Data.OleDb namespace is the .NET managed data provider for OLE
DB data sources. Whereas the System.Data.SqlClient namespace can be used to
access SQL Server 7, 2000, or 2005 databases, the System.Data.OleDb namespace
is used to access SQL Server 6.5 databases or earlier, as well as Oracle and Access
databases. Theoretically, the .NET Data Provider for OLE DB can access any
database where there’s an OLE DB Provider—with the exception of the Microsoft
OLE DB Provider for ODBC. Microsoft purposely restricted the capability to access
ODBC from the .NET Data Provider for OLE DB.
System.Data.OracleClient
The System.Data.OracleClient namespace is the .NET managed data provider for
Oracle databases. The .NET Data Provider for Oracle requires that the Oracle 8 or
higher client be installed on the system. The System.Data.OracleClient namespace
uses Oracle’s native OCI (Oracle Call Interface) to connect to Oracle 8 and higher

databases.
System.Data.Odbc
The System.Data.Odbc namespace is the .NET managed data provider for ODBC
data sources. Microsoft designed the .NET Data Provider for ODBC to be able to
access any ODBC-compliant database. However, Microsoft officially supports only
connections using the Microsoft SQL Server ODBC driver, the Microsoft ODBC
driver for Oracle, and the Microsoft Jet ODBC driver. However, we have successfully
used this provider to connect to DB2 databases as well.
Chapter 6: Developing Database Applications with ADO.NET 175
Core Classes for the .NET Data Providers
All of the.NET Data Providers included in the .NET Framework are essentially
architected the same. In other words, the classes contained in each namespace have
nearly identical methods, properties, and events. However, the classes each use
a slightly different naming convention. For instance, all of the classes in the .NET
Data Provider for SQL Server, found in the System.Data.SqlClient namespace, begin
with a prefix of “Sql”; the classes that are part of the .NET Provider for OLE DB,
found in the System.Data.OleDb namespace, all begin with the prefix of “OleDb”.
Both namespaces contain classes that are used to initiate a connection to a target data
source. For the System.Data.SqlClient namespace, this class is named SqlConnection.
For the System.Data.OleDb namespace, this class is named OleDbConnection. In
each case, the methods that are provided and their parameters are basically the same.
Because the function and usage of these classes are basically the same, they are
grouped together in the following section under their generic function names. The
following section presents an overview of the primary classes contained in the .NET
Data Provider namespaces.
Connection
The Connection class is used to open a connection to a target data source. A
Connection object is required in order to populate either the DataReader object or the
DataSet object with data from the target data source. Likewise, an active Connection
object is required in order to execute any commands or stored procedures that exist

on the database from the client .NET applications. Unlike most other .NET objects,
Connection objects are not automatically destroyed when they go out of scope. This
means that you must explicitly close any open ADO.NET Connection objects in your
applications. If multiple Connection objects are opened that use the same connection
string, they will be automatically added to the same connection pool.
NOTE
The actual functionality provided by the OleDbConnection class and the OdbcConnection class
is dependent on the capabilities of the underlying OLE DB Provider and ODBC driver. Not all
providers and drivers will necessarily support the same functionality.
Command
The Command class is used to execute either a stored procedure or a SQL statement
on the data source that’s associated with the active Connection object. Three types
of commands are supported: ExecuteReader, ExecuteNonQuery, and ExecuteScalar.
ExecuteReader commands return a result set. ExecuteNonQuery commands are used
176 Microsoft SQL Server 2005 Developer’s Guide
to execute SQL action queries like Insert, Update, and Delete statements that do not
return any rows. ExecuteScalar commands are used to execute stored procedures or
SQL queries that return a single value.
Parameter
The Parameter class is used to represent a parameter that’s passed to a Command
object. Parameter objects have properties that define their attributes. For instance, the
different properties of a Parameter object specify the parameter’s name, its direction,
its data type, its size, and its value. Parameter names are not case-sensitive, but when
naming Parameter objects that represent stored procedure parameters, naming the
parameter the same as the stored procedure parameter is typically a good idea. For
instance, if the Parameter object represents a stored procedure parameter named
@CustomerID, using that same name when instantiating the Parameter object is a
good practice. A Parameter object can also be mapped to a DataColumn in the DataSet.
DataReader
The DataReader class returns a forward-only stream of data from the target data

source that’s associated with the active connection object. Unlike objects in most
other ADO.NET classes that are instantiated by calling the constructor, objects
created from the DataReader class are instantiated by calling the ExecuteReader
method.
DataAdapter
The basic task of the DataAdapter class is to serve as a link between a DataSet object
and the data source represented by the active Connection object. The DataAdapter
class includes properties that allow you to specify the actual SQL statements that will
be used to interact between the DataSet and the target database. In other words, the
DataAdapter is responsible for both filling up the DataSet as well as sending changes
made in the DataSet back to the data source. For example, the DataAdapter class
provides the SelectCommand property, which controls the data that will be retrieved;
the InsertCommand property, which indicates how new data in the DataSet will be
added to the database; the UpdateCommand property, which controls how changed
rows in the DataSet will be posted to the database; and the DeleteCommand property,
which controls how rows deleted in the DataSet will be deleted from the database.
CommandBuilder
The CommandBuilder class provides a mechanism for automatically generating
the SQL commands that will be used to update the target database with changes in
an attached DataSet. The CommandBuilder uses the metadata returned by the SQL
Chapter 6: Developing Database Applications with ADO.NET 177
statement in the DataAdapter’s SelectCommand property to generate any required
Insert, Update, and Delete statements. Changes made in the DataSet are not
automatically posted to the database unless SQL commands are assigned to the
DataAdapter InsertCommand, UpdateCommand, and DeleteCommand properties or
unless a CommandBuilder object is created and attached to the active DataAdapter
object. Only one CommandBuilder object can be associated with a given DataAdapter
at one time.
Transaction
The Transaction class represents a SQL transaction. SQL transactions basically

allow multiple database transactions to be treated as a unit where an entire group
of database updates can either be posted to the database or all be undone as a unit.
The Transaction object uses the BeginTransaction method to specify the start of
a transaction and then either the Commit method to post the changes to the database
or the Rollback method to undo the pending transaction. A Transaction object is
attached to the active Connection object.
Error
The Error class contains error information that is generated by the target data source.
The active Connection object is automatically closed when an error with a severity
of greater than 20 is generated by the target database. However, the connection can
be subsequently reopened.
Exception
The Exception class is created whenever the .NET Data Provider encounters an error
generated by one of its members. An Exception object always contains at least one
instance of the Error object. You trap exceptions in your code by using the .NET
Frameworks Try-Catch structure error handling.
Core Classes in the ADO.NET
System.Data Namespace
The core classes that make up the ADO.NET technology are found in the .NET
Framework’s System.Data namespace. The following section presents an overview of
the functionality of the most important classes found in the System.Data namespace.
178 Microsoft SQL Server 2005 Developer’s Guide
DataSet
At the heart of the new ADO.NET architecture is the DataSet. The DataSet class is
located in the .NET Framework at System.Data.DataSet. The DataSet is essentially
a cache of records that have been retrieved from the database. You can think of the
DataSet as a miniature database. It contains tables, columns, constraints, rows, and
relations. These DataSet objects are called DataTables, DataColumns, DataRows,
Constraints, and Relations. The DataSet essentially allows a disconnected application
to function as if it were actively connected to a database. Applications typically need

to access multiple pieces of related database information in order to present useful
information to the end user. For example, to work with an order an application would
typically need to access a number of different database tables, including product
tables, customer tables, inventory tables, and shipping tables. All of the related
information from this set of tables can be grouped together in the DataSet, providing
the disconnected application with the capability to work with all of the related order
information that it needs.
In the disconnected model, going back to the data source to get each different
piece of related information would be inefficient, so the DataSet is typically
populated all at once via the active Connection object and DataAdapter from the
appropriate .NET Data Provider. A database connection is briefly opened to fill
the DataSet and then closed. Afterward the DataSet operates independently of the
back-end database. The client application then accesses the Table, DataRow, Data
Column, and DataView objects that are contained within the DataSet. Any changes
made to the data contained in the DataSet can be posted back to the database via the
DataAdapter object. In a multitier environment, a clone of the DataSet containing
any changed data is created using the GetChanges method. Then the cloned DataSet
is used as an argument of the DataAdapter’s Update method to post the changes to
the target database. If any changes were made to the data in the cloned DataSet,
these changes can be posted to the original DataSet using the DataSet’s Merge
method. Figure 6-2 provides an overview of the ADO.NET DataSet architecture.
DataTable
The DataTable class is located in the .NET Framework at System.Data.DataTable. The
DataTable class represents a table of in-memory data that is contained with a DataSet
object. The DataTable object can be created automatically by returning result sets
from the DataAdapter to the DataSet object. DataTable objects can also be created
programmatically by adding DataColumns objects to the DataTable’s DataColumns
collection. Each DataTable object in a DataSet is bindable to data-aware user interface
objects found in the .NET Framework’s WinForm and WebForm classes.