ADO is COM-based and is the data access technology of choice for VB6. DAO is even older and I don’t know, or want to know, much more about it. ADO.NET is what you should be using each and every time in .NET applications. The only time I have ever used ADO in a .NET app is when I was writing an add-in for an app written in VB6. The app exposed a method that returned an ADO Recordset, so I had to get my data from that. On no other occasion have I, or would I, use ADO. I suggest you adopt the same philosophy.

One of the major differences between ADO and ADO.NET is that ADO.NET uses a disconnected model. You connect to the database, get your data, disconnect, manipulate your data, reconnect, save the changes. With ADO you maintain a live connection the whole time you’re working with the data. Each model has its pros and cons but Microsoft have decided that, in this day and age, the disconnected model is better and I have to agree. The main issue with working disconnected is that two users may both retrieve, and then try to update, the same data. Microsoft provide plenty of information and advice on handling these concurrency issues though.

ODBC and OLEDB are both interfaces that provide a standard way to interact with different data sources. ODBC is older and more general. An ODBC driver exists for pretty much every database imaginable, and some data sources that couldn’t really be considered databases. There are also OLEDB providers for a large number of databases and other data sources.

ODBC is the older and should be considered a lowest-common-denominator. ADO.NET supports ODBC through the System.Data.Odbc namespace. You should only ever use ODBC through ADO.NET if there is no other choice.

OLEDB is a Microsoft creation and, like ODBC, provides a standard interface to databases and other data sources. An OLEDB provider exposes a standard set of functionality, while each OLEDB provider performs the necessary translation and talks directly to the individual data sources it was designed to support. An ODBC driver does the same. The .NET Framework supports OLEDB through the System.Data.OleDb namespace. OLEDB should be used in preference to ODBC but any more specific ADO.NET provider, e.g. SqlClient or OracleClient, should be used in preference to OLEDB.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s