[egenix-users] Installing mxODBC on Solaris 8

[Martin J. Evans]

On 20-Oct-2004 M.-A. Lemburg wrote:
> Martin J. Evans wrote:
>> I got it working like this:
>> 
>> http://www.easysoft.com/products/2002/mxodbc.phtml
>> 
>> Any feedback on this document welcome.
> 
> Editing mxCOMMERCIAL.py is definitely the way to go. I didn't
> even know that the stone old Makefile.pre.in approach still
> works with more recent Python versions.
> 
> BTW, what are the reasons for the "However, for recent versions of
> mxODBC (2+) we strongly recommend building mxODBC with unixODBC
> support." comment on that page ?
>
> While I agree that using an ODBC manager for better abstraction
> and easy of configuration, is there anything preventing the
> direct linking from working ?

Off the top of my head the reasons for this statement were:

1. the link I posted is to our web site and that document was to help
   people using mxODBC with our drivers which are all distributed with unixODBC.
   Lars Rehe said he wanted to use OOB.

2. We (Easysoft or rather Easysoft employees and specifically Nick Gorham)
   wrote a large percentage of unixODBC so we are:

   a) more comfortable and knowledgable with unixODBC
   b) can fix issues in it very quickly
   c) we supply multiple ODBC drivers and this doesn't work without a driver
      manager or multiple copies of mxODBC.

3. Using an ODBC driver manager allows you to configure mxODBC once and add
   ODBC drivers later without changing/rebuilding/reconfiguring mxODBC.

4. unixODBC offers ODBC API level tracing making tracking down issues easier.

5. unixODBC can protect non-thread drivers from threaded apps.

6. unixODBC supports connection pooling speeding up repeated connections
   massively.

7. unixODBC comes with odbcinst program which can be used to easily add drivers
   and data sources at install time vastly reducing installation problems.

8. a driver manager can isolate a program from ODBC 2 and ODBC 3 differences.

9. unixODBC supports the ANSI and Wide SQLxxx functions and can support UNICODE
   apps using a ANSI ODBC driver and vice versa.

10. DSN-less and FILEDSN connections are only meaningful with a driver manager.

11. A driver manager allows you to separate your application from a specific
    driver.

There is nothing "preventing the direct linking from working". In fact, as you
are probably aware, the URL I mentioned used to (a long time ago) direct you to
do this.

IIRC, the "(2+)" comment originates from the fact that mxODBC 2 added support in
the configure for driver managers (and specifically unixODBC) but you'd know
that better than me.

Basically the "strongly recommend" comes from the experience that getting
applications/interfaces to build/configure with unixODBC then add ODBC drivers
to unixODBC is easier and less error prone than directly linking with a driver
plus allows you to use multiple ODBC drivers.

Hope this answers your question.

As I said before, all comments/suggestions on the above URL welcome.

Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development