Today we are announcing that Microsoft is aligning with ODBC for native relational data access – the de-facto industry standard. This move supports our commitment to interoperability and our partners and customers’ journey to the cloud. SQL Azure is already aligned with ODBC today.
Conversations with our customers and partners have shown that many of you are already on this path. The marketplace is moving away from OLE DB and towards ODBC, with an eye towards supporting PHP and multi-platform solutions. Making this move to ODBC also drives more clarity for our C/C++ programmers who can now focus their efforts on one API.
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. We encourage you to adopt ODBC in any future version or new application development. For more information on Microsoft Support Lifecycle Policies for Microsoft Business and Developer products, please see Microsoft Support Lifecycle Policy FAQ.
For more information and resources, please see:
http://blogs.msdn.com/b/sqlnativeclient/archive/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access.aspx
To submit technical questions, please log onto:
http://social.technet.microsoft.com/Forums/en/sqldataaccess/threads
For more on SQL Server and Microsoft’s commitment to interoperability, see:
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.
Feeling lucky.
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.
Rohan Lam
Program Manager – SQL Server Connectivity Team
Great stuff guys, after gearing us for years towards OleDB and ADO.Net, you are now saying we have made the wrong choice.
So, shouldn't you create ODBC driver for the VFP's latest DBF format? 64 bit version, of course.
There will be Visual FoxPro reincarnation announced in a few years. I am sure.
msdn.microsoft.com/…/aa227291%28v=VS.60%29.aspx
I have read many times that OLEDB offers better performance than ODBC. Why is Microsoft now deprecating OLEDB in favor of ODBC ?
and what happens to developers who adapted their code with OLEDB so that they could refer to either a VFP backend or any other with a single code base? There is no chance to do that with ODBC. Or does MS mean to release a VFP ODBC driver as well?
Is this a joke? ODBC? That ancient technology from 20 years ago that we all stopped using because ADO.NET was better?
The irony is that we've now gone full circle – Microsoft was one of the original sponsors of ODBC some 17-18 years ago. So what they're really saying is that they made a mistake in moving away from their baby in the first place. Hey, maybe there will be a new ODBC wrapper for native OLEDB providers, just like when OLEDB first came out with a wrapper for ODBC. And where does Linq fit into this picture?
I was sure when I was reading this that I was reading an old post from April 1. Shocked to see it was written in August.
Ok, So three questions
1.So are you going to support a 64bit ODBC .net client? I can't believe that you must still compile your code into 32bit executables to be able to use ODBC
How long are we going to have to wait till SQL Azure going to play nice with ODBC
Is there any way currently to access SQL Azure from php on a linux box
ODBC is crap, OLEDB too. WCF would do the job perfectly. Or why should i create again a wrapper which wraps ODBC/OLEDB and re-expose it as WCF in a SOA oriented world?
So much for the “OLE DB is more reliable and faster” mantra. Perhaps Microsoft should switch from SQL Server to MySQL because that’s what the industry is doing as well?
Perhaps Microsoft should create a programming language called Dependability# that folks could rely on to deploy and keeps their apps running for decades at a time? As it is, a decimal point in a dot net revision breaks things and .net versions are outdated before mega development projects can even finish testing.
Microsoft “Where ‘did’ you want to go today?”