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















--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/4a3d64d0-f083-4393-9651-8171923bc...@openlinksw.com

Reply via email to