OLE DB was around well before ADO .NET and Microsoft will eventually drop support for it. But that will take quite a while because OLE DB providers have been written for a lot of data sources and a lot of applications depend on them. In fact, Microsoft depends of OLE DB to provide VB .NET and C# .NET access to data from many of their products - including Microsoft Access and Microsoft Exchange. You're also required use OLE DB if you want to access an Oracle database. Only one product - SQL Server - is natively supported by an ADO .NET managed provider.

The OleDb objects in System.Data.dll provide support in ADO .NET for any data source for which there is an OLE DB data provider. One in particular - ODBC - can be very useful for a lot of older data sources. Because there is an OLE DB provider that wraps ODBC, ADO .NET can work with virtually all legacy data.

The flowchart shows that there are two basic ways to access a data source through OleDb:

OleDbDataReader

and

DataSet

The bright colors used for DataSet in the chart above is a visual reminder that it's the more powerful technique. On the last page of the first article in this series, I used DataSet with OleDb to create an example XML file from the Microsoft Northwind database. Nothing is free and DataSet isn't quite as efficient as the technique we'll look at next. It can also involve more programming complexities.

The OleDbDataReader is a more streamlined way to access data. OleDbDataReader is a read-only, forward-only way to get data from a database. Although we won't take advantage of this here, DataReader can also improve performance by retrieving data as soon as it is available, rather than waiting for the results of the entire query to be returned. Microsoft notes that, "Results are returned as the query executes, and are stored in the network buffer on the client until you request them."