News

Microsoft Shifting Future SQL Server APIs from OLE DB Back to ODBC

• By Kurt Mackie
• 09/01/2011

Microsoft announced a roadmap shift, indicating that it will focus on supporting Open Database Connectivity for SQL Server application programming interfaces in the near future. The shift is of particular significance to C/C++ developers writing applications for relational database management systems, especially if they use other Microsoft-supported APIs, such as Object Linking and Embedding Database. Microsoft indicated that it will gradually step away from supporting OLE DB.

There will be a seven-year phase-out period for OLE DB, corresponding with the lifecycle support period of SQL Server code-named "Denali," after that product launches. Denali will be Microsoft's last SQL Server database management product to support OLE DB.

"OLE DB will be supported for 7 years from launch, the life of SQL Server Code Name 'Denali' support, to allow you a large window of opportunity for change before deprecation," Microsoft announced in a blog post. "We encourage you to adopt ODBC in any future version or new application development."

Microsoft released the third community technology preview version of Denali in July. The company hasn't announced a release date yet for Denali, but the common expectation is that Denali will be released sometime in the fourth quarter this year, with the details to come from Microsoft's PASS Summit 2011 event in October.

Ironically, Microsoft is accepting that the ODBC open standard it developed with Simba Technologies in 1992 has become the widely accepted standard for database APIs. ODBC has eclipsed Microsoft's other attempts to improve on the standard with its OLE DB, and possibly with its ActiveX Data Objects (ADO), at least according Simba's history of ODBC.

Microsoft hasn't indicated any deprecation to come with ADO itself. The support phase out is entirely focused on OLE DB.

"This deprecation applies to the Microsoft SQL Server OLE DB provider only," Microsoft explained in another blog. "Other OLE DB providers as well as the OLE DB standard will continue to be supported until explicitly announced."

Nonetheless, a Microsoft FAQ does indicate that ADO will be affected by the OLE DB phase out.

"Providers like ADO.Net which can run on top of OLE DB will not support OLE DB once the latter is deprecated," the FAQ states. "At that time the clients using the underlying provider need to update their application to use a different provider."

Developers should consider moving to ODBC over the seven-year period to align with this general roadmap change, Microsoft suggested. OLE DB was Microsoft's proprietary technology, but Microsoft now admits in the FAQ that ODBC was the "better choice."

"OLE DB was introduced primarily to provide uniform data access to non-relational data as well as relational data," the FAQ states. "But it is a Microsoft proprietary technology that worked only on Microsoft platforms. When it comes to uniform data access to SQL Server from different platforms, ODBC has always been a better choice and that was consistently quoted by all of our customers in various surveys, SDRs and forums. By fully aligning with ODBC, Microsoft will be focusing on one set of industry standard APIs that are widely used by many of our customers."

Microsoft already selected ODBC for its SQL Azure cloud-oriented database management system. From that standpoint, moving to ODBC-based APIs for SQL Server may make things easier for developers who are considering porting their SQL Server-based applications to Microsoft's cloud.

ODBC provides "an open, vendor-neutral way of accessing data stored in a variety of proprietary personal computer, minicomputer, and mainframe databases," according to a Microsoft Knowledge Base overview article. It requires three components to work: an ODBC-enabled client desktop application, an ODBC driver loaded on the front-end computer and a database management system server at the back end. The ODBC system can help applications work with various databases because the driver on the client converts commands into a form that the servers can understand.