This file contains instructions on running StarOffice with the
ODBC-ODBC Bridge. Easysoft have tested OOB with StarOffice 5.1 and
5.2beta.

To use OOB under StarOffice you should install the unixODBC driver
manager (either the version included with OOB or build unixODBC
yourself).  If you build unixODBC yourself please use
--enable-threads=no on the configure line. See http://www.unixodbc.org
for the unixODBC project and downloads.

OOB 1.0.0.13 for Windows contains a few fixes for problems highlighted
by StarOffice. The same applies to OOB 1.0.0.12 for UNIX so make sure
you have at least these versions.

StarOffice expects to find a driver manager on your machine as a
shared object called libodbc.<shared_object_extension>. If you have
already installed unixODBC or you choose to install the version
included with OOB the OOB installation will give you the opportunity
to configure OOB as an ODBC driver under unixODBC and create a demo
data source - you should do this. PLEASE READ THE IMPORTANT NOTE AT
THE END OF THE DOCUMENT ABOUT WHERE STAROFFICE LOOKS FOR THE DRIVER
MANAGER.

If you have the GUI unixODBC programs (you need QT for these) then you
can use ODBCConfig to create OOB data sources once OOB is installed as
an ODBC driver under unixODBC. Otherwise you will have to hand edit
the unixODBC odbc.ini file to add OOB data sources (see DSNDefinition
and example_odbc.ini in the OOB docs directory). Do not forget that
when OOB is used under unixODBC:

[1] Each DSN must contain a driver attribute telling unixODBC which
    ODBC driver the data source is for.
[2] If you built unixODBC yourself and used the default configure
    then:
    [a] please rebuild with --enable-threads=no.
    [b] you nolonger have to link /etc/odbc.ini to /usr/local/etc/odbc.ini
        as the OOB client will load unixODBC's libodbcinst library to
        get DSN information if it cannot be found elsewhere.

If you are connecting StarOffice to MS SQLServer through OOB you may
experience problems getting a list of tables in the database. This can
happen when MS SQLServer returns SQL_WCHAR (and SQL_WVARCHAR,
SQL_WLONGVARCHAR) for the column types in the call to SQLDescribeCol.
Some versions of StarOffice do not appear to accept the column types
SQL_Wxyz and refuse to obtain the data for these
columns. Unfortunately the columns it fails to retrieve often contain
the table name. To get around this problem add DisguiseWide = 1 to
your DSN definition - this is a workaround for StarOffice.

Where does StarOffice look for the ODBC driver manager?
-------------------------------------------------------

Our investigations on Linux (using strace) showed StarOffice looking
for the ODBC Driver Manager in the following places:

/opt/office52/program/libodbc.so
i686/mmx/libodbc.so
mmx/libodbc.so
libodbc.so
(wherever the dynamic linker looks for shared objects)

In this case StarOffice was installed in /opt/office52.

Be very careful if you have installed multiple ODBC driver managers or
multiple copies of an ODBC driver manager. StarOffice may locate the
incorrect one and this could lead to alot of problems.

On Linux, run ldconfig -v and check the first libodbc.so found by the
dynamic linker is the one you want to use.

On all platforms check the StarOffice tree for a
libodbc.<shared_object_extension> file and consider renaming it or
moving it so you can use unixODBC's driver manager.


