[unixODBC-dev] Problems with the way unixODBC switched to 64-bit SQLLEN

[M.-A. Lemburg]

Hi,

we are a company providing database adapters for Python and Python-
based software.

In recent months, we've received quite a few support requests from
users who had trouble using our products with unixODBC and various
different ODBC drivers.

One of them contacted EasySoft who then contacted us and mentioned
the change in sizeof(SQLLEN) that's been applied to the default
unixODBC configuration.

After some research, we found the following:

 * unixODBC 2.2.14 defaults to sizeof(SQLLEN)==8 on 64-bit platforms
 * this results in a change in the unixODBC ABI on 64-bit platforms
 * the unixODBC version number was only increased by a patch
   level release number - users don't really expect such a major
   change in a patch level release
 * the unixODBC 2.2.14 shared libraries still carry the same 1.0.0
   version, even though they are not compatible with the 2.2.12
   version
 * applications linked against 2.2.12 and expecting the 32-bit
   SQLLEN will happily use the 2.2.14 libraries and then fail
   on the user, e.g. not return any result sets or crash
 * Fedora has recognized some of these issues and now ships
   with unixODBC 2.2.14 libs that use 2.0.0 as .so version
 * Mandriva ships unixODBC 2.2.14, but uses the 1.0.0 .so version
 * OpenSUSE chose to stay with 2.2.12 for the time being

All in all, the situation is rather complicated.

We are now trying to find some way to provide our users with
a user-friendly solution to all this, but it's not at all
clear what to do:

 * we can't rely on the linker finding the right version
   based on the .so version
 * we can't test whether the library uses sizeof(SQLLEN)==8
   - at least not until the user has connected to a database
 * we can not even tell whether the unixODBC version number
   can be used as indicator, since some vendors may build
   unixODBC using the "legacy" 32-bit SQLLEN settings

I'd suggest to quickly move to unixODBC 2.3.0 to signal
the change in API to the user and bump the .so version
number to 2.0.0 (as already implemented by Fedora)
to clear up the situation again.

We could then tell our users to skip 2.2.13/14/15pre and
instead go straight to 2.3.0.

Some background about the .so version number logic:

    http://sources.redhat.com/autobook/autobook/autobook_91.html

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 17 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/