Microsoft Aligning with ODBC - Microsoft SQL Server Blog

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.

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:

http://blogs.technet.com/b/dataplatforminsider/archive/2011/08/29/microsoft-s-commitment-to-interoperability.aspx

Note: This blog post was updated on September 13^th, 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.

Join the conversation

Anonymous 2025 years ago

Feeling lucky.
Anonymous 2025 years ago

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
Pietje 12 years ago

Great stuff guys, after gearing us for years towards OleDB and ADO.Net, you are now saying we have made the wrong choice.
Pavel Celba 12 years ago

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.
chris 12 years ago

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 ?
Cetin Basoz 12 years ago

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?
Jeff 12 years ago

Is this a joke? ODBC? That ancient technology from 20 years ago that we all stopped using because ADO.NET was better?
Alain 12 years ago

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?
Scott 12 years ago

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.
Moshe Plotkin 12 years ago
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
1. How long are we going to have to wait till SQL Azure going to play nice with ODBC
2. Is there any way currently to access SQL Azure from php on a linux box
NickD 12 years ago

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?
Mark S 10 years ago

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?”
Comments are closed for this post.

Tags

Related blog posts

Capitalize on your investments with the new centrally managed Azure Hybrid Benefit for SQL Server

5 reasons to join us at Securely Migrate and Optimize with Azure

SQL Server 2022: Intel® QuickAssist Technology overview

Follow Microsoft