Hello Hugh, thanks for your post.
In theory any ODBC application should work with any ODBC Driver Manager and any ODBC Driver, but unfortunately particularly on Unix where a number for ODBC Driver Managers exist this is not the case due to subtle differences in implementations.
I also had the impression that drivers should be fairly independent, only providing a set of entry points according to the ODBC spec and therefore would work with any driver managers.
But there is also something like ODBC API version compliance. AFAIK the most recent ODBC API is at version 3.52 (correct me if I'm wrong), yet for some reason with the DataDirect drivers I see some numbers in readme indicating they require driver manager v 5.1 (or sth similar), which is a bit puzzling. Almost seems like they wanted to introduce their proprietry implementation as some sort of standard?
I have seen instances where ODBC Applications make use of what appears to be a custom Data Direct ODBC Driver Manager call SQLSetConnectAttr (SQL_ATTR_APP_WCHAR_TYPE) for example, which is not part of the standard ODBC specs and thus not implement by other ODBC Driver Managers or Drivers like UnixODBC or iODBC. As this is an ODBC API extension a well written ODBC application should cater for Driver managers or drivers that do not support this and have a fall back course of action to take, but unfortunately having not been tested with anything other than DataDirect fail when attempting to use others.
With iODBC and the OpenLink ODBC drivers we do try to track such differences in Driver Manager and Driver implementations such that our drivers work seemlessly with ODBC applications written with other Driver Managers, and are looking into the usage of this extension in the DataDirect Driver Manager.
Yes, you're right. IIRC I've seen a mention somewhere in ODBC guidelines that you should always try a feature and fallback in case it's not supported on some level of the stack. That's how say older drivers can be used with newer driver manager or application, etc.
In this case the application isn't a problem as it is within my control, i.e. I'm using Open Source components compiled against unixODBC (the choice of unixODBC was solely because I'm also using python with pyodbc which on Debian was packaged as compiled against unixODBC), and only using higher-level abstracts for database access (like python's DB-API). So there is nothing driver specific in my app.
It would be ideal if their was only one ODBC Driver Manager on Unix and many of these issue would go away as is the case on Windows were everyone used the Microsoft supplies ODBC Driver Manager and on Mac OS X where Apple now bundle the iODBC Driver Manager with their OS.
But unfortnately this is not likely to be the case on Unix anytime soon, due to the built up user base of the various ODBC Driver Managers availabe ...
I must admit I was quite confused by the existence of two driver managers when I first started working with ODBC. I suppose if both sides agreed, with some amount of effort it would be possible to merge both codebases even if they diverged considerably. It has been done in free software world already many times after all
Still it's not too bad in the sense that at least there is a common specification for ODBC to which all driver managers and drivers (should?) comply. This (at least in theory) gives us interoperability so that which driver manager you're using shouldn't be an issue, right?
What is the specific issue you are encountering as their are a number of issues to take into consideration ?
Now getting back to your first question. Current issues I'm having are:
- with Progress 9.1E driver I'm getting 'No host name.' error. Specifically, testing connection with isql gives (BTW, I've tried setting ODBCINI in environment before starting the program as suggested somewhere, but it didn't help):
Code:
[S1000][unixODBC][DataDirect][ODBC PROGRESS driver]No Host Name.
[ISQL]ERROR: Could not SQLConnect
- with OpenEdge 10.1C driver I get a segmentation fault (when stracing it, it seems it happens somewhere after opening the driver, which then tries to read $HOME/.odbc.ini)
Anyway, I'm suspecting a configuration issue somewhere, that's why I asked if someone who succeded with this setup could post their configuration. If not that I apparently know too little on the subject
(e.g. the DriverODBCVer driver setting confuses me a bit, as well as which settings should go to driver configuration (odbcinst.ini) and which to DSN configuration (\.?odbc.ini)).
Thanks again.
