Microsoft is Aligning with ODBC for Native Relational Data Access

EDIT (3/30/2018): OLE DB is now undeprecated. Read more about it here.

ODBC is the de-facto industry standard for native relational data access, which is supported on all platforms including SQL Azure. Cloud is universal and in order to support all client applications connecting from any platform to the cloud, Microsoft has been fully aligned with ODBC on SQL Azure, as ODBC is the only set of APIs that are available on all platforms including non-Windows platforms. From our surveys, cross-platform support is one of the main reasons indicated by our partners for aligning their applications with ODBC. The other reason often mentioned in the surveys is the ease of programming with ODBC. The interfaces are simple and straight forward. With this alignment, C/C++ developers can now focus on one set of APIs for all their native client applications. This will also make porting applications to cloud more seamless.

The commercial release of Microsoft SQL Server, codename “Denali,” will be the last release to support OLE DB. Support details for the release version of SQL Server “Denali” will be made available within 90 days of release to manufacturing. For more information on Microsoft Support Lifecycle Policies for Microsoft Business and Developer products, please see Microsoft Support Lifecycle Policy FAQ. This deprecation applies to the Microsoft SQL Server OLE DB provider only. Other OLE DB providers as well as the OLE DB standard will continue to be supported until explicitly announced.

We encourage you to adopt ODBC in the development of your new and future versions of your application. You don’t need to change your existing applications using OLE DB, as they will continue to be supported on Denali throughout its lifecycle. While this gives you a large window of opportunity for changing your applications before the deprecation goes into effect, you may want to consider migrating those applications to ODBC as a part of your future roadmap. Microsoft is fully committed to making this transition as smooth and easy as possible. In order to prepare and help our developer community, we will be providing assistance throughout this process. This will include providing guidance via technical documentation as well as tools to jump start the migration process, and being available right away to answer questions on our forum.

Update (October 19, 2011): In an effort to assist you with your planning, we have developed a tool that can scan your source code and provide a report showing the impacted code. This tool identifies and reports the lines of code that reference OLE DB APIs and provide a summary of the overall code impact. You can obtain this tool by sending an email by clicking 'Email Blog Author' link under the 'Options'. It will be available until April 18, 2012.

Please bookmark and revisit this site to see more tools and documentation updates.

For information on how to migrate your applications, please refer :

To see Frequently Asked Questions (FAQ) or to submit technical questions, please log onto:

For more on SQL Server and Microsoft’s commitment to interoperability, see:


Shekhar Joshi,

Sr. Program Manager - SQL Server Data Platform,

Microsoft Corporation

Note: This blog post was updated on September 13th, 2011 to reflect that the time frame for OLE DB support in SQL Server Code Name “Denali” will be made available within 90 days of release to manufacturing. We are committed to supporting features in SQL Server Code Name “Denali” through the product’s lifecycle as per Microsoft Support Lifecycle Policy.

A Quick Guide for OLE DB to ODBC Conversion.docx

Comments (40)

  1. Phil G says:

    I agree. We really do need an ODBC driver for SQL CE.

  2. Alfred says:

    It wold be great if Microsoft makes available an ODBC driver for SQL CE. It's a pending task since long ago !

  3. shekarN says:

    Hope MS will also force everyone to go back to using C /C++ for all new development!

  4. Robert S says:

    Why not going back to DBLIBRARY ! :0)

  5. Brandon K says:

    I think this is great news!  

    I am very excited to see SQL Server hop back on the ODBC (standards-based!) bandwagon.

  6. Jamie Thomson says:

    I just want to point out to anyone reading this that as of today (9th March 2012) migrating your SSIS applications to using ODBC might not be a great idea. Here's why:…/odbc-in-ssis-2012.aspx

  7. As much as I love Microsoft Bob, I can't remember the last time there was a new release of that software.  

    ODBC, on the other hand, has been improved.  For example, the Windows ODBC driver has had significant updates in both Windows 7 and in (not yet released) Windows 8. For more info, see…/ee388580(VS.85).aspx.

    And, of course, in SQL Server Native Client, the ODBC driver is updated to support the new features in the server.  For example,…/cc280510(SQL.100).aspx and…/cc280510(SQL.110).aspx.

    I'm not trying to minimize the impact of removing OLE DB provider support from SQL Server Native Client.  But I do want to correct any notion that ODBC has been in mothballs.


    David Schwartz

    SQL Server Documentation

  8. Matthew Cunningham says:

    I guess that we should now expect a major update to Jet DB as well? Perhaps FoxPro 2012 is comming out soon too? How about Microsoft Bob for SQL Server?

  9. James Horsley says:

    So when are Microsoft going to make an ODBC driver available for SQL CE then – this is so overdue already it is madness.

  10. Zeroninesevenone says:

    If ODBC will match the performance (hopefully getting even better) and the capabilities of the OLEDB, then good. But ODBC needs better tools and manageability. The catalog of connections is a good thing, makes life easier for admins and other support activities.

  11. mike smith says:

    If you want 'set in stone' for ten years, may I suggest you picked the wrong industry. </wry comment>  

    True, OLE DB is faster, but that's more because it's been under active development all this time.  ODBC hasn't, so much.  Give it another chance.  I'm hoping Microsoft don't change it so much that it will no longer be cross platform.

  12. Richard Jones says:

    I was actually referring to native unmanaged ADO and not ADO.NET.  I believe when using unmanaged ADO it will just be a case of replacing Provider=SQLOLEDB with DRIVER={SQL Server} in the connection string to switch from OLEDB to the ODBC driver but I'd like to get confirmation on this. Thanks.

  13. দীপ ঘোষ says:

    ODBC is too old. Please dont use it.

  14. Martin Richter says:

    Unbelievable for me…

    Years ago Microsoft sayed to us: Don't doit in ODBC, use OLE DB this is the future.

    And it was OK. OLE DB is much fatser than tis crapy ODBC stuff.

    And now we have all based on OLE DB and now the next SQL-Server Version is the last that supports it.

    And all this because they have trouble getting their own OLE DB stuf running in the cloud.

    But anyhow: Who cares for the cloud? 😉

  15. I mean the ADO.NET SQL Server provider does not use the SQL Server OLE-DB or ODBC drivers.

  16. ADO.NET does not use either OLE-DB or ODBC.

  17. Rohan Lam - MSFT says:

    Please note, this announcement applies to SQL Server Native Access Client (SNAC) OLE DB provider only and it does not apply to other OLE DB providers either from Microsoft or 3rd party software vendors. SNAC provider is used primarily with native applications (C, C++) connecting to Microsoft SQL Server.

    For managed applications (C# or .Net), we still recommend using ADO.Net and we are continuing to invest in it. For more information, please see:…/microsoft-sql-server-oledb-provider-deprecation-announcement.aspx

    For other questions, please see our FAQ on our Data Access forum:…/e696d0ac-f8e2-4b19-8a08-7a357d3d780f. You can also post your questions there.

    This blog is not very convenient for interactive questions.

  18. Richard Jones says:

    If only using ADO and not OLE DB directly will an application be impacted? i.e. Will Microsoft be updating ADO to use ODBC and not OLE DB under the covers?

  19. Vladimír Cvajniga says:

    Best solution: swith to non-Microsoft technologies.

  20. Dreads kooi says:

    Odic is standard and works with any db so I think this is good, yes they can maybe improve interface to define these odbc connections.

Skip to main content