With ADO 2.6, developers only had three objects to work with when accessing and manipulating data: the connection, command, and record set objects. While these objects were innovative at the time of their release, they now pose inherent problems as we strive for a distributed model of systems development. ADO record set objects are difficult to share across computing platforms and cannot penetrate firewalls. Additionally, if a record set is created as a result of a JOIN query, the original data sources can be difficult to update.

ADO.NET has been created with a multitude of objects that are designed to carry out very specific functional tasks and solve the problems listed above. These objects come in two varieties: SQL Server optimized or Ole-DB. This is of particular significance to developers who are using a full suite of Microsoft tools to build their applications. If SQL Server is your database of choice, ADO.NET provides you with a set of objects that bypass the Ole-DB provider and directly access SQL Servers tabular data stream. This direct access to SQL Servers proprietary API provides noticeable performance gains. If you are accessing MS Access, Oracle, Sybase, etc., you have a completely different set of classes that encompass the same functionality as the SQL Server optimized objects, but through an Ole-DB provider.

To access the ADO.NET functionality, you must import namespaces, which house the data objects we need to carry out specific functions, into the pages you create. The following is a listing of the main namespaces required to manage data in the .NET environment:

System.Data

Exposes objects used to access and store relational data. The DataSet, DataReader, and DataRelation objects are used to create relational data stores in virtual memory. These objects are independent of data source, meaning that relational SQL Server data, XML, or array data, for example, can be accessed using the same type of properties and methods. This namespace should most likely be imported into every .NET page that accesses data. Some objects of this namespace include:

DataSet
DataTable
DataRow
DataRelation

System.Data.OleDb

Contains the objects that allow us to access data through an Ole-DB provider. These objects, as mentioned earlier, have the same properties and methods as the SQLClient namespace that I will cover next. Objects include:

OleDbConnectin
OleDbCommand
OleDbDataSet
OleDbDataReader
OleDbDataAdapter

System.Data.SQLClient

Encapsulates all the functionality that we need to do any type of data reading or manipulation from Microsofts SQL Server Objects include:

SQLConnection
SQLCommand
SQLDataSet
SQLDataReader
SQLDataAdapter

As you can tell by comparing the names of each object in the OleDb and SQLClient namespaces, the objects are built exactly alike for different access methods. This is a distinction that you as a developer will not have to be concerned with once you choose your data source.

Just from the onset, it is very obvious that the expanded classes can provide us with much more functionality than we have ever had in the past.