Namespace Organization

The types (classes, structs, enums, and so on) associated with each .NET data provider are located in their own namespaces:

• System.Data.SqlClient. Contains the SQL Server .NET Data Provider types.
• System.Data.OracleClient. Contains the Oracle .NET Data Provider
• System.Data.OleDb. Contains the OLE DB .NET Data Provider types.
• System.Data.Odbc. Contains the ODBC .NET Data Provider types.
• System.Data. Contains provider-independent types such as the DataSet and DataTable.

Within its associated namespace, each provider provides an implementation of the Connection, Command, DataReader, and DataAdapter objects. The SqlClient implementations are prefixed with "Sql" and the OleDb implementations are prefixed with "OleDb." For example, the SqlClient implementation of the Connection object is SqlConnection, and the OleDb equivalent is OleDbConnection. Similarly, the two incarnations of the DataAdapter object are SqlDataAdapter and OleDbDataAdapter, respectively.
In this guide, the examples are drawn from the SQL Server object model. Although not illustrated here, similar features are available in Oracle/OLEDB and ODBC.

Generic Programming

If you are likely to target different data sources and want to move your code from one to the other, consider programming to the IDbConnection, IDbCommand, IDataReader, and IDbDataAdapter interfaces located within the System.Data namespace. All implementations of the Connection, Command, DataReader, and DataAdapter objects must support these interfaces.
It should also be noted that both the OLE DB and ODBC bridging providers are alternatives if an application uses a single object model to access multiple databases. In this situation, it is important to consider the application's need for flexibility, and the extent to which database-specific functionality is required, in comparison with the application's need for performance.

Shashi Ray