Odbc Version 17 Download

0 views

Skip to first unread message

Fairy Dawdy

unread,

Aug 3, 2024, 5:03:09 PM8/3/24

to fooranseci

Your computer may contain a variety of ODBC drivers, from Microsoft and from other companies. This topic describes how to use the Windows ODBC Data Source Administrator to check the version of the installed ODBC drivers.

Microsoft ODBC Driver for SQL Server is a single dynamic-link library (DLL) containing run-time support for applications using native-code APIs to connect to SQL Server. Use Microsoft ODBC Driver 18 for SQL Server to create new applications or enhance existing applications that need to take advantage of newer SQL Server features.

The redistributable installer for Microsoft ODBC Driver 18 for SQL Server installs the client components, which are required during run time to take advantage of newer SQL Server features. It optionally installs the header files needed to develop an application that uses the ODBC API. Starting with version 17.4.2, the installer also includes and installs the Microsoft Active Directory Authentication Library (ADAL.dll).

Version 18.3.3.1 is the latest general availability (GA) version. If you have a previous version of Microsoft ODBC Driver 18 for SQL Server installed, installing 18.3.3.1 upgrades it to 18.3.3.1. The Microsoft ODBC Driver 18 for SQL Server can be installed side by side with Microsoft ODBC Driver 17 for SQL Server.

If you are accessing this page from a non-English language version, and want to see the most up-to-date content, please select Read in English at the top of this page. You can download different languages from the US-English version site by selecting available languages.

Version 17.10.6 is the latest general availability (GA) version of the 17.x driver. If you have a previous version of Microsoft ODBC Driver 17 for SQL Server installed, installing 17.10.6 upgrades it to 17.10.6.

The Microsoft ODBC Driver for SQL Server can be downloaded and installed using package managers for Linux and macOS using the relevant installation instructions:
Install ODBC for SQL Server (Linux)
Install ODBC for SQL Server (macOS)

The package runs fine locally, but whenever I run it on the server, I'm having trouble with the ODBC data source. The driver on the server is the exact same one with the exact same name as the one on my workstation.

To get the package into the server, I've imported the dtsx file into SSIS in Stored Packages. I've also tried to deploy the project to the Integration Service Catalog, but I get one of these failures related to the ODBC source when doing so --

I've looked at the dtsx file (xml based) and I suspect that there is a conflict with the DTSID for the ODBC driver. I'm not sure how that works but it seems like that ID would be unique for each computer and that SSIS is getting is trying to use the workstation's DTSID on the server.

I'm a bit new to SSIS and Visual Studio so I'm hoping I'm assuming there is a straightforward way to run packages developed on a workstation at the server without these hangups. I just can't find anything specific to this problem anywhere.

EDIT: I added a second sentence in the 2nd error message above. It refers a connector provided by Attunity, which is something I don't understand. The ODBC driver installed on the system is from Data Direct. The CLSID returned in the error message is also associated with an Attunity connector in the server's registry.

There are no ODBC drivers from Attunity showing up in either of the ODBC managers, so it's possible that these are somehow part of a default install or were installed when our server used to have SSDT and VS installed directly on it and were never uninstalled. Or, something else?

I have resolved this issue by changing the Deployment Target Version of Integration Services project in VS in my case from SQL Server 2017 to SQL Server 2016 (the target SQL version). Hope this helps. Old quesition, but came up first in google when I tried to solve my problem.

I had this same problem when executing my package in SQL Server Agent. I resolved it by turning on the Execution Options "Use 32 Bit Runtime" flag in the agent step. Drove me nuts for a few days, hope this helps.

check the version of your solution vs the SQL version of where you are deploying. I had this issue and matching up versions fixed the problem. My solution was 2017 but the SQL box was 2016. I had to change the solution to 2016. cheers!

In my situation I was having this error and I switched to using the 32-bit version. My initial test worked, then I redeployed using a the project I was working with and I got this error again, even though I had switched Execution Options "Use 32 Bit Runtime" flag.

It ended up that I was having problems with my ODBC Data Source. I was using IBM Informix driver and it was having an issue with the chosen locale. I changed it to use the server's specific local and tested its connection. That then worked and my SSIS package worked on the server.

I am trying to make sure i get the best performance when connecting and downloading from an oracle database. I have installed Oracle Instant Client, and just upgraded to version 19_10. I thought this would result in a new driver version when running my workflows, however the messages indicate in am running ODBC Driver version 03.52, which i believe is the version i had before, when i was using Instant Client 12_2.

There is apparently no recent version available for version 13. We already have ODBC driver 17.10.4.1 and ODBC driver 18.2.2.1 installed, so we duly uninstalled ODBC driver 13.3.6430.49 from the server.

A "Microsoft ODBC driver 13 for SQL Server" warning popped up highlighting that the SQL Server Agent service was dependent on this driver version. And as expected, after uninstalling ODBC driver 13, the SQL Server Agent service refused to start.

We have only been able to obtain ODBC driver 13.0.811.168 from the Microsoft website, so now our driver is even more out of date! On a different server running the same build of SQL Server 2016, it lists ODBC Driver 13 as being version 14.0.1000.169, and this has not been flagged as a vulnerable version, but we cannot find anywhere to download this version from!

So the question is, how do we resolve this vulnerability without breaking the SQL Server Agent service? Why is the SQL Server Agent service on our machine still dependent on ODBC driver 13 when drivers 17 and 18 are available? Where can we obtain ODBC Driver 13 build 14.0.1000.169 from?

As per the above and attached, we already have ODBC driver 17.10.4.1 and ODBC driver 18.2.2.1 installed. We don't understand the dependency that the SQL Server Agent service has on the ODBC driver 13.

This could be the reason the SQL server agent service is not starting if SSIS, R objects, and others components were installed, and the ODBC driver was removed. You may consider running a repair on the SQL server installation.

We recommend that customers who are running ODBC versions 11 and 13 as part of an application outside of a SQL Server installation update to ODBC versions 17 or above or OLE DB versions 18 or above, which provide protection against this vulnerability. ODBC and OLE DB driver installations that are part of a supported SQL Server installation will be updated via SQL Server cumulative updates or general distribution release updates.

What installer would have created these ODBC DLLs? We have a few severs where the SQL Server 2016 builds are exactly the same (13.0.6430.49), but on some of the servers the ODBC version 13 drivers are 13.0.811.168 (i.e. vulnerable) and on others they are 14.0.1000.169 (i.e. not vulnerable). So we feel less confident that a future CU will address this.

I can't speak for your Informix drivers specifically but in general (did I just say that) newer data access drivers are backward compatible to older versions of the platforms they connect to. Maybe you could try a newer version of the Informix driver that conformed to the ODBC 3.0 spec and can also connect to your older Informix database instance.

2) work through flat files: draw flat files from Informix using whatever native bulk export tool they provide (they provide one right?) and have SSIS call that bulk export tool to get a flat file and then start from there loading the flat file

Unfortunately unloading data to flat files is a no go flat files are all pipe delimited, not text qualified and users type pipes in free text. derr. also being a sco 5.0.7 system the htfs file system cannot handle files > 2gb in size so some tables will fail to unload anyway.

the PHP option is the best one available if I can't get the direct odbc running properly but I fear that will be unbelievably slow. as it is, this process DOES work on other servers so I might be able to fix it yet...

Are you seriously wanting to run 2GB datasets through SSIS as a part of a regularly scheduled job or are we talking about a migration here? If that ODBC driver does not support paging out data in a stream as it comes available (some platforms/drivers have to build the entire dataset in memory before anything is returned to the ODBC consumer) then I think you could have issues anyway. Have you ever pulled that much data at one time out of this Informix instance before?

I am thinking that having a PHP web service proxy 2GB of data as an XML document for SSIS is doomed-from-the-start. With that much data I rescind my PHP shim idea unless you use offsets to only nibble off small batches of data until you have brought everything over you wanted.

Wow, that's neat! I have seen the error you originally posted on different forum sites but don't ever remember seeing a resolution where the original poster traced it back to a firewall or networking issue. Did you simply have to open the Informix-specific ports between the server running SSIS and the server hosting Informix? I am only asking so that this post may eventually help someone else with the same issue.