PGEO driver should not force MDB Tools on Unix platforms

[kyngchaos@…]

The automatic registration of the MDB Tools driver should not be a requirement, but an option. For those who can't use MDB Tools (OSX) or for some other reason want to use a different ODBC driver for Access, they can't, because the MDB Tools load fails (if not installed) or overrides any other (if installed).

Before trying to register the MDB Tools, is there some way it can check the ODBC system if an Access driver is already loaded?

[warmerdam]

Mateusz,

I'd appreciate it if you could consider this before the 1.4.0 release is finalized.

[mloskot]

I understand that default installation of MDB Tools driver on Unix is not recommended.
I'm sure, I can check if there is any MDB driver already installed.
If there is one, OGR will not try to install it.

But I'm still not sure I understand what alternatives to MDB Tools we have, if any.

What MDB drivers can be used on Unix instead of MDB Tools?
What if there is no MDB tools and no other MDB driver is installed, then accessing Personal Geodatabase seems to be not possible. Am I correct?

Summarizing, we need ODBC layer + MDB tools driver to use OGR PGeo driver.
For Unix platforms (Linux mainly), we have tested unixODBC + MDB Tools.
What else ODBC and MDB drivers on Unix we can support?
If there are any, I will try to add their support and test with OGR.

William, I'm also going to try to make MDB Tools + unixODBC working on OSX but it may need some time.

Thanks for any suggestions!

[kyngchaos@…]

Sounds like you have a good idea what's available for linux.  I'm thinking mainly of Mac OS X.  There is a commercial iODBC driver for Access from Actual (actualtechnologies.com).  Although I've been having a little trouble with it reading binary fields, but the developers of the driver are looking into it so it should work when bugs are worked out. (Note: I patch GDAL to use iODBC that comes with OSX.  I have a feature request for GDAL to add that as a config option.)

I looked at the MDB Tools with the thought of trying to build it on Mac OS X, but I was turned off by the Gnome requirements - glib and friends.  Tho it looks like I would just need glib for just the library without the extra tools.  There isn't a technical problem building glib, I've built it in the past on OSX, I'm just a lazy whiner.

But I have heard others say that they've had problems getting MDB Tools to work on OSX.

[mloskot]

(In reply to comment #3)
> Sounds like you have a good idea what's available for linux.

Yes, this subject on Linux is pretty well tested.

> There is a commercial iODBC driver for Access from Actual
> (actualtechnologies.com).

First good news is that iODBC is called "Open Source platform" so I believe it's freely available.

The Access driver you've mentioned is commercial, so I believe if it is supposed to be supported, it should be optional for GDAL users.
Do you know if it's the only Access driver for Mac available or may there are 
other implementations, closed or open source?

Frank,
what do you think about adding support to OGR for iODBC + Access
driver from Actual Technologies?

> Although I've been having a little trouble with it
> reading binary fields, but the developers of the driver are looking into it so
> it should work when bugs are worked out. (Note: I patch GDAL to use iODBC that
> comes with OSX.  I have a feature request for GDAL to add that as a config
> option.)

Does it mean you've almost ready support for iODBC + Access driver from Actual Technologies?
 
> I looked at the MDB Tools with the thought of trying to build it on Mac OS X,
> but I was turned off by the Gnome requirements - glib and friends.

glib is the only requirement for MDB Tools driver.
I agree, it may not be good solution for most Mac users to require glib installation to use ODBC + Access on Mac.

> But I have heard others say that they've had problems getting MDB Tools
> to work on OSX.

I've also experienced unstable behavior of MDB Tools on Linux, so I assume it's not a mature driver yet.

Please, give me some time to discuss iODBC option.

[mloskot]

William, if you are able to provide iODBC support patch for OGR PGeo driver, that would be great. I can assist you to include it into OGR.
I can also try to test it on Mac with trial version of AT's driver for Access.

Does it make sense for you?

[kyngchaos@…]

What a coincidence, I just heard back from Actual today with a fixed Access driver.  I'm checking it out now, but I'm having trouble with the exportToWkt() function segfaulting, but at least it looks like it's reading binary data now.

For iODBC support option, first an option is configure is needed so iODBC is used in place of UnixODBC.  Basically -liodbc and -liodbcinst instead of -lodbc and -lodbcinst (quick-n-dirty method: find and replace).  Basic ODBC headers are the same, but the odbcinst header has a different name for iODBC, iodbcinst.h, so a switch is needed in port/cpl_odbc.h depending on the configed ODBC used to include the correct odbcinst header.

Note: I must have been thinking of GRASS for the iODBC feature request.  I didn't see one in the GDAL bug list.  So I guess this is a combined pgeo bug and iodbc request ^_^

Within the pgeo driver itself, it's automatic, as long as ogrpgeodriver.cpp doesn't try to register/install the MDB Tools driver (my quick hack was to comment that out).

Oh, and yes, this is the only non-bridge Access driver I was able to find for OSX.

[warmerdam]

William,

Is there still a pending action item here? I'd like to treat the MDBTools ODBC driver as unsupported, but if there is a functioning ODBC driver on MacOS X and we need to change something to make it practically useful, let me know and I'll try to have Chaitanya work with you on it.

[kyngchaos]

Per the original report, the main problem is that the pgeo format *always* tries to load the MDBTools ODBC driver. And if it fails, the format fails to load. There is no way to specify an alternate ODBC driver, or simply skip MDBTools and expect a driver to be available automatically that can handle Access DBs.

The existence of an Access ODBC driver for OSX is secondary. If I or someone can figure out how to get MDBTools working on OSX (interest is quite low), the existing code is fine. If not, and another ODBC driver works (still no luck on that Actual driver!), pgeo needs to be able to handle that possibility.

PS. I recently had an idea for a workaround to the lack of a working Access driver on OSX: I found a Java program (mdb-sqlite) that converts MDB to SQLite (presumably working on OSX, haven't had a chance to test it yet). Then all that's needed is a custom pgeo driver that reads from SQLite, that shouldn't be too difficult.

[warmerdam]

William,

I've changed the OGRPGeoDriver::Open() code to attempt to install the MDBTools driver, but to only report a warning if it fails, and continue on. This change is in trunk (r18168). If this seems like an adequate approach, and you wish it back ported let me know and I can push this into 1.6 branch as well.

[kyngchaos]

The warning sounds good. It's been so long and I don't see either of the current ODBC drivers working any time soon (maybe I'll find some time to poke at MDBTools again), so it's fine for a 1.7 release.