Database Reference
In-Depth Information
Table 10-5.
Commonly Used
Odbc
Classes
Classes
Description
OdbcCommand
Executes SQL queries, statements, or stored procedures
OdbcConnection
Represents a connection to an ODBC data source
OdbcDataAdapter
Represents a bridge between a data set and a data source
OdbcDataReader
Provides a forward-only, read-only data stream of rows from a data source
OdbcError
Holds information on errors and warnings returned by the data source
OdbcParameter
Represents a command parameter
OdbcTransaction
Represents a SQL transaction
Data Providers Are APIs
The .NET Framework data providers, sophisticated as they are (and you'll learn plenty about exploiting
their sophistication later), are simply APIs for accessing data sources, most often relational databases.
(ADO.NET is essentially one big API of which data providers are a major part.)
Newcomers to ADO.NET are often understandably confused by the Microsoft documentation. They
read about
Connection
,
Command
,
DataReader
, and other ADO.NET objects, but they see no classes named
Connection
,
Command
, or
DataReader
in any of the ADO.NET namespaces. The reason is that data provider
classes implement
interfaces
in the
System.Data
namespace. These interfaces define the data provider
methods of the ADO.NET API.
The concept is simple. A data provider, such as
System.Data.SqlClient
, consists of classes whose
methods provide a uniform way of accessing a specific kind of data source. This is true of all ADO.NET
facilities, whatever kind of data source you need to access.
The SQL Server data provider is optimized to access SQL Server and can't be used for any other
DBMS. The OLE DB data provider can access any OLE DB data source. The ODBC data provider lets you
use an even older data access technology, again without knowing anything about it. Working at such an
abstract level enabled you to do a lot more, and a lot more quickly, than you could have otherwise.
ADO.NET is not only an efficient data access technology but also an elegant one. Data providers are
only one aspect of it. The art of ADO.NET programming is founded more on conceptualizing than on
coding. First get a clear idea of what ADO.NET offers; then look for the right method in the right class to
make the idea a reality.
Since conceptual clarity is so important, you can view (and refer to) connections, commands, data
readers, and other ADO.NET components primarily as abstractions rather than merely objects used in
database programs. If you concentrate on concepts, learning when and how to use relevant objects and
methods will be easy.
