Data access mess explained

Thanks to the Daily Grind, today I found the (begining of an) answer to a question I've wondered about for some time: why does Microsoft have so damn many data access APIs? The answer is being provided in a series of blog entries by Mike Pizzo of the Microsoft Data Programmability team. I'm adding him to my RSS aggregator.

If you've been a Visual Basic programmer for any length of time, you know all about this. Between DAO, RDO, ADO, ADO.NET, and so forth, it feels like Microsoft is reinventing data access every couple of years. Some of these are real, genuine improvements (I quite like ADO.NET, now that I'm used to it), but a lot of it seems completely superfluous. It's almost like the data access guys ran out of things to do and are trying to justify the fact that they're still getting pay checks.

So far, I like the explainations. I even learned something, like what the purpose of RDO was. The summary so far is:
ODBC = Standard C-style Call Level Interface for RDBMSs.
DAO = Access database scripting.
RDO = Like DAO, but without going through Jet (the Access database engine).
ODBCDirect = A mode in DAO to avoid the overhead of using ODBC through DAO.
So, in other words, RDO and ODBCDirect seem to be a bit redundant. They both appear to be work-arounds for VB not being able to do ODBC in a performant way, i.e. other than through Jet.

I'll be looking forward to the next installment. So how is ADO going to fit into this mix?

You can reply to this entry by leaving a comment below. You can send TrackBack pings to this URL. This entry accepts Pingbacks from other blogs. You can follow comments on this entry by subscribing to the RSS feed.

Add your comments #

A comment body is required. No HTML code allowed. URLs starting with http:// or ftp:// will be automatically converted to hyperlinks.