Multiple SQL Server Native Client Versions

One of the big problems with the old MDAC was different versions on different client machines. You would test your app with the latest version say, but when you deployed it, it might fail as the client has a different version.

My company develops software for Municipal Government clients. These clients use other SQL Server applications as well as ours, but they can only use one version of the client software (MDAC) on a given desktop. That means if we require a particular MDAC version, but the clients other applications from other vendors don't officially support that MDAC version, the client is in a real jam.

Our software also supports Oracle, which allows our software to specify a particular Oracle Home which points to a directory with a particular version of the Oracle client dlls (along with corresponding registry entries for that Oracle Home), such that we control the exact client version of the Oracle software that the client uses with our applications. This will not interfere with, and is completely seperate, from the default Oracle home installed when you install the Oracle client software.

What I would like to see for the Native Client is the ability to have our applications use the version of the Native Client that we wish to support and deploy without interfering with the Native Client version used by other applications. Have a default Native Client, but allow applications to somehow specify a different Native Client version/set of DLLs.

Is there any such functionality with the Native Client? (I didn't see any mention of such in the documentation, but I thought I'd ask)

If not, are there any future plans to support multiple Native Client versions on the same desktop?

At present, there is only one version of the SQL Server Native Client, so the particular issue you've raised isn't technically a concern at this point (which may explain why you didn't find any obvious discussion of the topic).

In the SQL Server Native Client blog, Chris and/or Acey discuss the history of issues that were encountered with multiple versions of MDAC and specifically discuss the issue you've brought up above (the blog posting is at: http://blogs.msdn.com/sqlnativeclient/archive/2006/09/27/774286.aspx ). They go on to specifically mention:

By wrapping the OLE DB and ODBC technologies into a single library, we are able to avoid these issues by making a clean break from MDAC so that you can effectively deploy SQL Native Client as needed, without concern about if it will “play nicely” with other versions of MDAC.

So, for you app today, you can build against the SQL Server Native Client and deploy that application (including the SQL Server Native Client redistributable) to your clients without breaking existing MDAC based applications.

As to the future, making this clean break only to commit to the same course of action with the new SQL Server Native Client would be less than ideal and we are actively considering how best to support this need in the next release that will come with future versions of Microsoft SQL Server. If you have specific scenarios or issues you would like considered, we would very much like to hear your ideas.