FAQ Q: Why did you develop ODBC Manager? Isn't there already ODBC Administrator? A: Apple stopped including the ODBC Administrator with Mac OS X starting with the release of Mac OS X 'Snow Leopard'. ODBC Manager is functionally equivalent to Apple's administrator, while fixing many of its problems and annoyances. Q: My company makes an ODBC driver for our database - can we include ODBC Manager with our installer? We encourage all ODBC vendors to include ODBC Manager with their installer. Q: Our application supports ODBC, be we don't ship any drivers with our applications.

Can we include ODBC Manager with our installer? We encourage application developers to include ODBC Manager with their installers. Q: Where can I get ODBC drivers for Mac OS X? A: The following vendors sell commercially supported drivers for Mac OS X:.

Q: I have a question about ODBC Manager - who do I contact? A: Send an e-mail to.

Hello everyone, Newly registered to these forums, but I've been around for some time now I wanted to ask about experiences with the Progress supplied DataDirect ODBC drivers (I've access to versions from 9.1 and 10.1) and a GNU/Linux standard ODBC driver manager (e.g. UnixODBC preferably or iODBC). Has anyone had any luck getting that combination to work? I know DataDirect supplies their own driver manager for some reason, but I cannot/don't want to use it (mostly because I'm working on an application which connects to many different databases and I'm not going to recompile every other driver to work with a closed, proprietary driver manager).

I know there are alternatives, like using JDBC or an ODBC-JDBC bridge and I'm looking into them now, but I guess it would be more efficient to be able to use these drivers directly. Anyway, if you have any (preferably positive:awink: ) experiences, please, could you say few words about how you got it going, possibly post relevant parts of your /etc/odbcinst.ini && /etc/odbc.ini $HOME/.odbc.ini? Hi Mike, What is the specific issue you are encountering as their are a number of issues to take into consideration?

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 have seen instances where ODBC Applications make use of what appears to be a custom Data Direct ODBC Driver Manager call SQLSetConnectAttr (SQLATTRAPPWCHARTYPE) 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. 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. Best Regards Hugh Williams OpenLink Software.

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 (SQLATTRAPPWCHARTYPE) 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.

Datadirect Drivers For Oracle

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.

Datadirect Drivers For Oracle

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. 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?

S1000unixODBCDataDirectODBC PROGRESS driverNo Host Name. ISQLERROR: 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.