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 : https://msdn.microsoft.com/en-us/library/hh967418.aspx
To see Frequently Asked Questions (FAQ) or to submit technical questions, please log onto: https://social.technet.microsoft.com/Forums/en/sqldataaccess/threads
For more on SQL Server and Microsoft’s commitment to interoperability, see: https://blogs.technet.com/b/dataplatforminsider/archive/2011/08/29/microsoft-s-commitment-to-interoperability.aspx
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
Anonymous
August 30, 2011
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?Anonymous
August 30, 2011
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...Anonymous
August 30, 2011
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.Anonymous
August 30, 2011
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.Anonymous
August 30, 2011
The comment has been removedAnonymous
August 30, 2011
--> What is the overriding motivation? <--Anonymous
August 31, 2011
These are all good questions, please see the answers here: social.technet.microsoft.com/.../e696d0ac-f8e2-4b19-8a08-7a357d3d780f If you have further questions feel free to post in the forum and I will provide more details.Anonymous
August 31, 2011
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.Anonymous
August 31, 2011
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...Anonymous
August 31, 2011
If this means that horrible ODBC dialog will finally get a facelift, then I'm all for it!Anonymous
September 01, 2011
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!Anonymous
September 01, 2011
It must be April 1 in the Northern HemishphereAnonymous
September 01, 2011
The comment has been removedAnonymous
September 01, 2011
The comment has been removedAnonymous
September 02, 2011
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 cheersAnonymous
September 09, 2011
It seems that Microsost has lost compass completely.Anonymous
September 09, 2011
That's the price to pay for dealing with a monopoly.Anonymous
September 11, 2011
Gotta love those System DSN's. Love 'em.Anonymous
September 12, 2011
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 IBMAnonymous
September 12, 2011
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!Anonymous
September 12, 2011
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.Anonymous
September 12, 2011
Best solution: swith to non-Microsoft technologies.Anonymous
September 12, 2011
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?Anonymous
September 14, 2011
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: blogs.msdn.com/.../microsoft-sql-server-oledb-provider-deprecation-announcement.aspx For other questions, please see our FAQ on our Data Access forum: social.technet.microsoft.com/.../e696d0ac-f8e2-4b19-8a08-7a357d3d780f. You can also post your questions there. This blog is not very convenient for interactive questions.Anonymous
September 15, 2011
ADO.NET does not use either OLE-DB or ODBC.Anonymous
September 15, 2011
I mean the ADO.NET SQL Server provider does not use the SQL Server OLE-DB or ODBC drivers.Anonymous
September 22, 2011
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? ;)Anonymous
September 23, 2011
ODBC is too old. Please dont use it.Anonymous
October 13, 2011
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.Anonymous
November 29, 2011
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.Anonymous
December 13, 2011
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.Anonymous
January 16, 2012
So when are Microsoft going to make an ODBC driver available for SQL CE then - this is so overdue already it is madness.Anonymous
January 20, 2012
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?Anonymous
January 20, 2012
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 msdn.microsoft.com/.../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, msdn.microsoft.com/.../cc280510(SQL.100).aspx and msdn.microsoft.com/.../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. HTH David Schwartz SQL Server Documentation dschwart@microsoft.comAnonymous
March 08, 2012
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: sqlblog.com/.../odbc-in-ssis-2012.aspxAnonymous
August 08, 2012
I think this is great news! I am very excited to see SQL Server hop back on the ODBC (standards-based!) bandwagon.Anonymous
November 20, 2013
Why not going back to DBLIBRARY ! :0)Anonymous
December 13, 2013
Hope MS will also force everyone to go back to using C /C++ for all new development!Anonymous
October 21, 2015
It wold be great if Microsoft makes available an ODBC driver for SQL CE. It's a pending task since long ago !Anonymous
November 25, 2015
I agree. We really do need an ODBC driver for SQL CE.