Showing posts with label old. Show all posts
Showing posts with label old. Show all posts

Wednesday, March 7, 2012

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.

Multiple Sources & Destinations...

Hello,

I am working on a typical data conversion project where we are migrating data from an old data model to a new data model, using SSIS. Both the DBs are in SQL.

Now we have a situation where say there are 25 source tables and 20 odd target tables.

For transporting data, we are using OLEDB Source & OLEDB Destination transforms. However, each transform maps to one view or one table. As a result, the Data Flow is really messed up with 45+ transforms in it. Is there an elegant way of doing this ? With say just one datasource or maybe fewer transforms?

Thanks,

Satya

I would have one Data Flow for each set of source and destination tables. Only cover related tables min each. I assume this means 20 tasks as you have 20 destination tables.