Tuesday, September 27, 2011

Microsoft to switch back to ODBC from OLE DB, say reports

By Vasudev Ram - dancingbison.com | @vasudevram | jugad2.blogspot.com

Surprising as it may seem, Microsoft may switch back to ODBC from OLE DB.

I read about this a few days ago on the Net.

Here are some relevant links to the news about Microsoft going back to ODBC.

From the Microsoft SQLNCli team blog (I guess SQLNCli stands for SQL Native Client):

Microsoft is Aligning with ODBC for Native Relational Data Access:


From the blog of Hal Berenson, former Distinguished Engineer and General Manager, and who, in his own words, "was both a godfather of the OLE DB strategy and responsible for the SQL Server implementations that have now been deprecated":

OLE DB and SQL Server: History, End-Game, and some Microsoft "dirt":


Interesting stuff. I had worked some years ago on a middleware product that involved ODBC - that sat on top of ODBC, actually (*). One of its main goals was to improve the performance of ODBC-based client-server applications. (Another goal was a more programmer-friendly API for application programmers working on client-server projects that used ODBC, in Visual Basic as well as C.) The product was a success, and was deployed in several large client-server projects of the company I worked for at the time.

Also, the Java JDBC API and the Perl and Python DBI API's were probably influenced quite a bit by the architecture / design of ODBC. (This is what I think, based on having studied and worked on both ODBC and JDBC a good amount, and some on the Perl and Python DB APIs). It (ODBC) was a pretty good technology for its time, and was very extensively deployed and used (almost universally, in fact, for client-server database applications), during the heyday of the client-server period of computing - though native database drivers were also used a lot then.

Interesting to see that Microsoft is now moving back to it - presumably, to improved versions of it, suited to today's requirements.

(*) If you are wondering how another software layer on top of ODBC could improve performance of ODBC apps, rather than only make it worse (due to more overhead of the extra layer), think a bit more. It may sound counter-intuitive, but is possible - it actually happened.

Posted via email

- Vasudev Ram @ Dancing Bison

No comments: