More debug messages for unixODBC issues
alippai opened this issue · 7 comments
On one of my CentOS 7 machines I have an unixODBC issue which I can't figure out how to solve.
odbcinst -j works, loads the correct ODBCSYSINI env variable. My unixODBC version is 2.3.1
isql -k ... works, successfully connects
odbc2parquet throws unixODBC error S1009, Invalid attribute value (native error 0)
even odbc2parquet list-drivers throws the same error, so it's not about the DSN
ODBC Environment created is also printed
Would it be possible to add some more details to the error message? (I tried -v -vvv etc)
Some progress:
- Checking with strace didn't really help, I see that it opens the correct odbcinst.ini files which work.
- I downloaded the odbc2parquet, odbc-api and odbc-sys repositories. It's likely that the outdated unixODBC version is the culprit, I believe it doesn't support Odbc3_80 (it dies when setting that attribute)
Installing unixodbc in a conda environment and setting the LD_LIBRARY_PATH to the conda lib dir resolves the issue.
Hello @alippai ,
Would it be possible to add some more details to the error message? (I tried -v -vvv etc)
Adding more details to a specific ODBC diagnostic messages is not possible, as these messages are created by the driver manager (and in most other cases also by the driver of the data source itself).
Adding more context however is an entirely different matter. We can probably always improve in the dimension of explainig to the user what the application has been trying to do as the error occurred. In the specific case you experienced the error would have always been the same, but the artefact could have provided context, that it occurred while trying to specify the ODBC Version.
These log messages are probably best added upstream to the odbc-api crate.
Cheers, Markus
Yes, I agree. I'll try to add an error message for the unsupported ODBC version in odbc-api
Adding more details to a specific ODBC diagnostic messages is not possible, as these messages are created by the driver manager (and in most other cases also by the driver of the data source itself).
I feel a bit stupid. We can of course always translate the error returned by ODBC. Thankfully you provided enough details to spare any future soul experiencing the same problem the debugging you had to do.
Fixed upstream in odbc-api: pacman82/odbc-api@dd849fb
I'm sorry for being slow on this. The change looks good, thank you