laidpans mallorie madden
Tracee Hsiang
There is a connect.dat file in the program file with a line saying "OLE DB Provider = MSDASQL". Changing this entry alters the error message I get to "Provider cannot be found, it may not be properly installed".
It is important that your ODBC driver's executable and linking format (ELF) is the same as your application. In other words, you need a 32-bit driver for a 32-bit application or a 64-bit driver for a 64-bit application.
If these do not match, it is possible to configure a DSN for a 32-bit driver and when you attempt to use that DSN in a 64-bit application, the DSN won't be found because the registry holds DSN information in different places depending on ELF (32-bit versus 64-bit).
Be sure you are using the correct ODBC Administrator tool. On 32-bit and 64-bit Windows, the default ODBC Administrator tool is in c:\Windows\System32\odbcad32.exe. However, on a 64-bit Windows machine, the default is the 64-bit version. If you need to use the 32-bit ODBC Administrator tool on a 64-bit Windows system, you will need to run the one found here: C:\Windows\SysWOW64\odbcad32.exe
Where I see this tripping people up is when a user uses the default 64-bit ODBC Administrator to configure a DSN; thinking it is for a 32-bit DSN. Then when the 32-bit application attempts to connect using that DSN, "Data source not found..." occurs.
This was not the first time I have come to this page searching for the same error message. Unfortunately, Microsoft error messages are vague and often several different issues will cause the same error message, hence why there are so many answers here.
The problem is that when I am opening an ADODB connection in VBA, and I use this same string, it will produce the "[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified" error.
Following the instructions here =27099554 I had to install the Microsoft Access Database Engine 2010 Redistributable before I had the Excel driver installed to use the DSN-less connection I wanted to use from perl.
I had the installed drivers listed in odbcinst -q -d, and could connect manually but not through R's odbc::dbConnect(). Turns out I forgot a semicolon in the connection string: .connection_string = "TrustServerCertificate=yes;"
During a recent vulnerability scan, it was identified that Microsoft ODBC drivers have a vulnerability that requires us to resolve via update. I wanted to confirm that these ODBC updates will not break the application's connection to the backend DB. Has anyone applied the latest Windows ODBC drivers? We are running 2023.3 but soon updating to 2023.4.
No issues and/or impact here when upgrading to the latest v17 ODBC driver (that was supports recommendation - as SCM uses v17), I'm not exactly sure what the ODBC driver is utilized for within the SolarWinds Platform however.
What was your procedure? I just installed EOC and the internal vulnerability scaner detected an updated verison. The microsoft udpates are disabled on the server and I might need to do a manual upgrade of the ODBC driver
No impact to SolarWinds Platform services when upgrading the ODBC driver and never ran into any issues. I'd recommend reaching out to SolarWinds support if you use SCM however to determine what exactly it uses it for potentially and what the impact to that product may be.
Otherwise - the process is easy, download the latest v17 version of the ODBC driver from Microsoft, copy to server, run installer on ALL polling engines (Primary, Additionals, HA standbys if applicable) - and in your case the EOC server which is basically a polling engine with regard to what gets installed. The installer just runs and doesn't require any reboot at all.
I have the native ODBC driver and I can connect from command line and python (pyodbc) without any issues, but from JMP I'm always getting a "not found" error regardless if I try to connect from JSL with open database() or from the query builder.
And i can get it to work with ActualTech ODBC Driver without rosetta2 but i have some kerberos domain issues with that driver. I liked the ActualTech documentation and ODBC Manager, thanks for the tip @bryan_boone. If i can get the domain issues sorted i'll continue with those drivers, the cost is not significant.
Long story short, the Micosoft SQL Server ODBC Driver seems to be only unixODBC which JMP does not support.
I do it with the ActualTech ODBC drivers. The ODBC driver is set up with either ODBC Manager or the IODBC Administrator. You might be able to test out (or even configure) your install with either of these apps.
Thanks Bryan,
yes that's the reference, as you can see it is biased against unixodbc and not iodbc/ODBCmanager.
I've actually had this on hold for a while only using a python connection from JMP to do the query since everything works fine with pyodbc through python.
I've today for the first time managed to get iODBC to accept another driver and it works fine through JMP in a JSL script (even though the UI for the query builder is acting out and does not allow me to pick any schemas or tables to work against).
That got me hooked on trying to get my ms sql servers up and running in the same way, but i still can't make it happen.
iodbc just shows these kinds of errors when i click test (even if i make a DSN straight out of the documentation):
If i hit the same DSN from python and pyodbc it works without any errors... I am wondering if it can be something with the encoding but iodbc or jmp are not really giving me a lot to troubleshoot on.
iODBC is at least not understanding how the driver is working, that's my only conclusion so far.
I guess i need to try other drivers...
So, my apt-get install returns with E: Unable to locate package msodbcsql (error code 100). I'm trying to access an SQL Server database with my system, and so I'm following Microsoft's instructions to install their driver for Linux.
I've tried specifying the package version: apt-get install -y msodbcsql17 and using the package for both Debian 8 and 9. I've tried to confirm the system version, as I'm actually building a Docker container from Debian:stretch-slim -> Python:3.6-slim, and I'm leaning towards Debian 8, because the version number in other images is explicitly 9.
This is more like avoiding the problem than actually fixing it, but it works for now. The issue is changing the version requires manual location of the new file, which is not ideal, but perhaps I'll get things working more smoothly some other time.
I found the raw package file using the links provided in the documentation I mentioned in the question. For me the URL was and the latest package was msodbcsql17_17.2.0.1-1_amd64.deb. Using wget and dpgk I managed to install that package.
I spent the last hour trying to connect to a mssql server using sqlcmd through odbc driver.I was talking to the db guy but he doesn't seem to have a clue what is going on.. Maybe you can help me out to find some questions I could ask that guy..
I was hitting a similar issue. It turns out that the \DEV04 part of the hostname\DEV04 is used to indicate that the client should be connecting to the server on a different port from the default. In the Microsoft world, using DEV04 automatically ensures that the client connects to the correct port... but that doesn't seem to work with the Linux sqlcmd.
The UDP protocol just won't work in Linux using the Microsoft provided ODBC tools and sqlcmd. The UDP portion is used initially to probe the server to find the TCP port the requested database is listening on.
As the error message hints at, it's a concurrency issue; Your application attempted to call the DB server with a request while the connection was busy with a prior request. This happens if you are executing statements asynchronously.
I'm not sure if it could have something to do with D12. Because it used to work. But with D11.3 and older ODBC drivers. And there were also Windows updates on the PC and I don't know if there were changes on the server.
the main changes are, first i open the FDQuery and copy the data to a FDMemTable, after that i close the FDQuery and my While loop are working with the TDMemTable dataset to with the query. So i got no exception and the UPDATE Statements is working well. Strange...
Could be a difference in the number of rows in the result set with a larger result set not getting all fetched on open. Various options to fetch them all before processing. The default is usually 50 records at a time.
I only had the FDQuery open and FDCommand was then executed in the While Loop. Nothing else, as shown in the example, I only deleted the Firebird statemens, but this is a different FireDAC connection.
i can't check that, because on the productivity server i can't play and on my developer PC it has no made any problems. So the server on my customer and my MS-SQL Express test enviroment must have some differences.
Seems like the SQL CU 22 corrects the issue on the DB servers but not app or web servers. I just wanted to put a reply out there to see if anyone else is running into this issue with ODBC drivers and if anyone has seen a fixlet for this or have created one to help remediate the issue.
I am developing a web application that involves connecting PHP with SQL Server, in order to do so it was necessary to download and install the Microsoft ODBC Driver 18 for SQL Server for Windows; reading the license it mentions in the part of "Installation and use rights" that "You may install and use any number of copies of the software to develop and test your applications", I wonder if I wanted to market (not develop or test) my web application so that other users connect to my server, where I have Microsoft Driver 18 for SQL Server installed, through a web browser to make use of my application that needs the Microsoft Driver 18 for SQL Server to be able to work (not to download the driver but to use my web application), is it possible to do it with that driver that I have downloaded or should I buy some other driver or application that allows me to market my application? If so I would like to know why.
c01484d022