What provider should I choose for my VB6 ADODB connection to SQL Server 2014?

Question

I'm not sure how to interpret this quote from the MSDN documentation. Is the native client deprecated?

There will be no more updates to the ODBC driver in SQL Server Native Client. The successor to the ODBC driver in SQL Server Native Client, which is called the Microsoft ODBC Driver 11 for SQL Server on Windows, is installed with SQL Server 2014.

The OLE DB Provider in SQL Server Native Client was last updated in SQL Server 2012 Native Client. Developers who wish to use an OLE DB provider to connect to the latest version of SQL Server must use the OLE DB provider that shipped in SQL Server 2012 Native Client.

I also found this statement on msdn.

Microsoft has announced the deprecation of the SQL Server Native Client OLE DB provider, and that SQL Server 2012 is the last version of SQL Server to support the provider. This article provides guidance for converting SQL Server or SQL Azure applications that use OLE DB to the ODBC API.

Connection string samples for the different suggestions is also helpful :)

Answer 1

These statements imply that the older drivers will no longer receive updates, and instead will be replaced by newer drivers. You should test your VB6 app using the new Microsoft ODBC Driver 11 for SQL Server on Windows. OLE DB and ODBC are independent technologies, so the quotes you found do not relate to each other. The first quote applies to your situation. My suspicion is that it will simply work. ODBC drivers are agnostic to the language the calling applications are written in, so you'll be fine.

Answer 2

I believe all of this reflects Microsoft's move away from desktop Windows as the primary client platform as they move their server products (e.g. SQL Server) into Azure.

The Linux and Apple ecosystems never adopted COM, and so stayed away from OLE DB since they lacked the necessary infrastructure. The same remains true for younger OSs such as Android and Chrome OS.

On the other hand while ODBC is a cruder technology it has been widely adopted outside of Windows, spawning thin wrappers and work-alikes such as JDBC drivers.

By moving away from Windows technologies such as OLE DB Microsoft is in a better position, both to support other client OSs and to move SQL Server to another OS running in Azure since they see a "Windowless" future ahead.

...

As far as VB6 development goes in the interim, I'd stick with the SQL Server 2012 Native Client OLE DB provider just as Microsoft suggests. But you might want to begin looking elsewhere for client development tools since VB6 and even VB.Net appear to be nearing the end of the road. Soon there might not be a lot left of .Net at all aside from C# supporting the bits and pieces in .Net Core.