Microsoft is Aligning with ODBC for Native Relational Data Access

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. Markus J. says:

    Wait a second, wasn't it ODBC that has been hidden very well in Windows 7 and also been declared as "obsolete" by Microsoft a long time ago? Wasn't it ODBC which was recommendet by Microsoft to move away from and start using OLE-DB and ADO.NET as the future API for Database Access?

  2. Alberto López Grande says:

    For years, MS has been conducting us in OLE DB direction, that most of us have followed. Now, you are telling us that we are going in the wrong way… What if you change your point again in the next seven years?

    And most important, how are we going to explain to our customers, bosses, followers, etc., who changed their applications to use OLE DB after we told us that "ODBC is the past, OLE DB is the future"?

    Sometimes it seems that you are in the other team…

  3. This does not make sense. What will happen to the linked servers support, cross-DB replication, SSAS and many other MS and non-MS applications that can only work via OLEDB? Does it mean that Denali will support linked servers via ODBC?

    Looks like a poor decision.

  4. MattK says:

    This may turn out to be a good decision. If ODBC regains first class status as an data access API, then interoperability between SQL Server and non-MS platforms will likely be improved.

  5. SteveH says:

    This seems crazy!  I agree that OLE DB is complicated – but then most people are using ADO.NET for simple scenarios.  For performance and flexibility, OLE DB has been vastly superior to ODBC.  Can we expect the same performance from the new ODBC driver implementation?  Will we have full access to all features?  What is the overriding motivation?

  6. FremyCompany (RT @SteveH) says:

    –> What is the overriding motivation? <–

  7. Rohan Lam - MSFT says:

    These are all good questions, please see the answers here:…/e696d0ac-f8e2-4b19-8a08-7a357d3d780f

    If you have further questions feel free to post in the forum and I will provide more details.

  8. Peter says:

    What's the story with the native SQLClient when used from/by .NET? Does that depend on OLEDB, would it be effected by this change? What about the performance of the next version of SQL Server when used from .NET, any changes? Thanks.

  9. mahara says:

    So this is all about OLE DB provider in SQL Server only. But, what about Microsoft-wide strategy regarding this matter, for example in future Windows version (Windows 8 and beyond)? Will they all be be FINALLY deprecated too? It's related to the question asked by Markus J. above. I agree with him. I thought this whole ODBC thing has already been deprecated, but it seems it's being resurrected and instead OLE DB that is being deprecated. Such confusing strategy…

  10. Damian Powell says:

    If this means that horrible ODBC dialog will finally get a facelift, then I'm all for it!

  11. Nigel Page says:

    Will you please just make a decision and stick to it! Those of us who guide organisations through technology change have had a torid time with Microsoft data access technologies over the years and quite frankly, have just about had enough. This needs to be a 'set in stone' 10 year guarantee of direction!

  12. Harry says:

    It must be April 1 in the Northern Hemishphere

  13. giorgio says:

    microsoft after lost 30% programmers with c# and 1 -2, will lost another 40% with tihs decision!

    Microsoft is CRAZY, the DAL is completx too for web based commercial site…

    PHP will win

  14. Eduardo says:

    So, the old "OLEDB is faster" was crap? Please clarify

  15. Paul says:

    ODBC was always the better option, its interoperable it well known.

    But you're confusing your customer base, its annoying, stop it please.

    Prepare to get it in the ear at many conferences, some people hang on to this stuff, but its neither here nor do as long as it doesnt mean redevelopment effort

    Much love cheers

  16. Robert says:

    It seems that Microsost has lost compass completely.

  17. Tarik says:

    That's the price to pay for dealing with a monopoly.

  18. piers7 says:

    Gotta love those System DSN's. Love 'em.

  19. Steve says:

    Once again MS proves you cannot trust a word out of their mouths.

    reminds me of ActiveX

    you would think they would have figured out a data access standard by now…

    this kind of stuff is why people abandon MS and go with IBM

  20. LULZOID says:

    so they couldn't get OLE DB to work on the cloud so they are going to hamstring everybody in their attempt to get them to go cloud…brilliant way to anger your entire development community!

  21. 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.

  22. Vladimír Cvajniga says:

    Best solution: swith to non-Microsoft technologies.

  23. 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?

  24. 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.

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

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

  27. 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? 😉

  28. দীপ ঘোষ says:

    ODBC is too old. Please dont use it.

  29. 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.

  30. 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.

  31. 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.

  32. 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.

  33. 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?

  34. david_vcp says:

    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

  35. 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

  36. 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.

  37. Robert S says:

    Why not going back to DBLIBRARY ! :0)

  38. shekarN says:

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

  39. Alfred says:

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

  40. Phil G says:

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