Bug#509815: Dropping iODBC from Debian/Ubuntu, see Debian bug #509815
Hi Heinrich,
> in Debian bug #509815 there is an open discussion to drop
> iODBC from Debian (which will result in dropping it from
> Ubuntu).
>
> Looking at the iODBC.org and the iodbc.sourceforge site
> there seems to have been no new developments in the last
> two years.
>
> Do you plan to further support and develop iODBC?
The short answer is yes on both accounts.
First of all we do support iODBC and the ODBC API in general actively both towards our own customers as well as the general public who have questions on how to use ODBC API in their own or third party applications as well as assist in debugging issues relating to both open source and commercial drivers. We have an active support system in place for anyone with questions, bugreports etc to go to, as well as mailing lists, forums etc hosted by sourceforge.net.
We actively assist other open-source projects to enhance their ODBC offering, for instance the code changes we contributed to PHP project to both 5.2.x and 5.3.x branches to allow their ext/odbc code to fully work in 64bit mode which up to 5.2.6 was completely impossible. We also fixed the handling of the various ODBC Cursor models in the PHP code. Another project we are currently actively involved in is KDE/Soprano/Nepomuk, which uses another open-source product from us called Virtuoso which is also available on most platforms including Debian and Ubuntu. We also advised them on the usage of ODBC in general, not specifically towards the use of iODBC.
As for new developments go, please note that the ODBC spec has been stagnant after Microsoft finished the last big revision (the 3.52 in 1997-1998) which we implemented. As we have no intentions to add new API functions itself as long as these will not be available for Windows. For a long time Microsoft pushed people to ditch ODBC in favor of ADO, however there are rumors that they are going to revive the ODBC standard which we hope will bring some enhancements to the areas that were not well defined/explained in the last standard. We continue to track developments in this area and when this calls for fixes/additions to the iODBC driver manager code, we will of course make them.
However we are working on one extension to the ODBC standard which deals with UNICODE support. In all of their documentation Microsoft was very vague about the definition and use of SQLWCHAR, especially when it comes to non-Windows platforms. So when we interpreted the standard, we mapped it to the platform native wchar_t which seemed to make the most sense at the time since this would allow C, C++ to define the size and it should work with the native libraries in a portable manner. OpenLink's own ODBC drivers were programmed to do the translation between internal formats of the db (ucs2, ucs4, utf8 etc) to the platform native format which is 16bit wide on Windows (using UTF16 encoding), and 32bit wide on most UNIX platforms (using UTF-32). Note that the specs indicate this translation lies with the driver.
This approach allowed the user to use standard constructs like:
SQLHANDLE hstmt;
SQLWCHAR * my_cmd;
....
my_cmd = L"select * from account";
SQLPrepareW (hstmt, my_cmd, SQL_NTS);
which works on both Microsoft and Unix platforms.
However other projects (like unixODBC and QT) chose at some point to use a 2byte UTF-16 encoded multibyte equivalent for portability on all platforms, which means that all ascii strings need to be converted before they can be used. For the ODBC standard this means that translation needs to be done within the application, instead of the driver.
In light of this we started to make an addition to the existing iODBC driver manager code to allow the driver manager to work in both 2 and 4 byte mode at both ends (application and driver). Development is not going as fast as i would like, since other commercial developments have a higher priority, but we are currently trying to iron out the last bugs before release.
As for having both unixODBC and iODBC concurrently on a platform, i see no reason why this would be any problem for the runtime parts since they do not overlap at all. There is a potential problem with the location of the header files, but we could easily change this for debian (or any other system) to be installed in /usr/include/iodbc and add the -I/usr/include/iodbc to the iodbc-config script.
There are many libraries and programs providing similar functionality in any distribution, allowing the users a choice which they want to use.
One of the features a lot of iODBC users like is the fact that it very readable trace logs containing both both symbolic and values for all arguments which allows the user to better understand the sequence of instructions that are send to the driver and the return values which may influence the behavior of their application.
I welcome anyone to contact me if they have questions about iODBC or any other OpenLink product, and i hope i am allowed to participate in this discussion for the continued shipment of iODBC on the Debian platform.
Best regards,
Patrick
---
Patrick van Kleef
Manager Open Source Projects
OpenLink Software
Reply to: