Re: Status of ODBC driver managers on Unix

> -----Original Message-----
> From: Peter Eisentraut [mailto:peter_e(at)gmx(dot)net]
>
> Hiroshi Inoue writes:
>
> > Provide subdirectories for compilation e.g. ./iODBC
> > ./unixODBC ./Windows. Each subdirectory would have
> > its own makefile at least and specific sources like
> > gpps.c for iDOBC if necessary. Common sources are
> > still in the current directory but the objects would
> > be put into the each subdirectories when the compilation
> > is invoked.
>
> Something like that, but where do you install the drivers? E.g., you'd
> have ./iODBC/libpsqlodbc.so and ./unixODBC/libpsqlodbc.so, but when you
> install them the names clash again.

AFAIK the driver's name of unixODBC is libodbcpsql.so currently
and doesn't conflict with libosqlodbc.so.

> This could be easy to arrange with two make targets that link in a
> different library, but the subject of include files is tricky. I'm not
> sure if it's reasonable to have both iODBC and unixODBC installed since
> they both install some of the same files, such as sql.h and sqlext.h.
>
> > I'm not sure about how to change the current iODBC
> > support. I didn't find the library in iODBC like
> > odbcinst in unixODBC.
>
> The version 3.0.5 I'm looking at contains a library libiodbcinst which
> contains the function SQLGetPrivateProfileString.

Hmm we may be able to have a common driver for unixODBC,
iODBC(newer) and Merant DM(according to Nick Gorham).
Is it possible to provide a dummy libodbcinst and link it at compile
time ? If so we don't need the packages at build time though
there remains a problem where/how to find sql(ext).h.

>
> > If there are some people who expect continuous iODBC support, gpps.c
> > should be removed or improved at least.
>
> Probably removed.
>
> But another thing that occurred to me is that if you want to use ODBC on
> Unix for ApplixWare or StarOffice you don't necessarily have a driver
> manager installed with header files and such, so we probably need to keep
> the standalone version.

Agreed.

regards,
Hiroshi Inoue