Re: - verifying that an ODBC connection is correctly defined

Patricia Merritt wrote:
> I am attempting to use a ODBC driver provided by Egan Systems Inc to connect
> to a file on a Linux server that is in their proprietary ISAM format (I am
> quite successful using this driver on the W2K but need to be able to use it
> in both environments). Because we've run into problems trying run our
> "application" with their driver in Linux,I thought perhaps I could test the
> ODBC install/config/definitions via your isql utility.
>
> - We have extracted, compiled, and installed UnixODBC.
> - We have installed the Icobol package (in usr/Cobol332)
> - We have run
> odbcinst -i -d -f template_icodbc
> where template_icodbc is
>         [ICODBC]
>         Comment   = Interactive COBOL ISAM ODBC Driver for Linux
>         Driver    = /usr/cobol332/libicodbc32.so
>         FileUsage = 1
> - We have run
>  odbcinst -i -s -f template_file
> where template_file is
>         [ABS_account]
>         Description         = Test IC Dataset
>         Driver              = ICODBC
>         DBQ                 = /usr/cobol332/ABSdata/Case_ProdFOX_mod
>         Threading           = 3
> - we are running the icpermit required of Icobol
> - there is a Case_ProdFOX_mod.xdb in /usr/cobol332/ABSdata and it points to
> CaseProd.xdt and CaseProd.nx and xd
>
> - we can connect to ABS_account using your isql utility but in response to:
>
> SELECT * from Cases WHERE CASE_NO = 6
>
> it generates a slew of messages in the SQL log
> ODBC[871][SQLSetCursorName.c][121]Error:SQL_Invalid_Handle
>
> Is it a mistake to believe that we could use isql for this purpose?
>
> I've sent a message to Egan support but thought perhaps you might shed some
> light on this question as well..
>
> thanks for any help you can provide ...
Hi,

I am just guessing (but it is a informed guess), they have built their 
driver so that it makes calls to its own ODBC functions. This is a real 
"bad thing" on linux, and what happens is the calls in the driver to (in 
this case) SQLSetCursorName end up in the driver manager not the driver.

The solution is for the driver writers to either

1. Change the internal references so they don't call ODBC API calls, but 
some internal version

2. Recompile the code with -Wl,-Bsymbolic on the compile line (this 
assumes gcc).

--
Nick Gorham

Easysoft Limited
web: www.easysoft.com
tel: +44 (0)1937 860000
fax: +44 (0)1937 860001

This email from Easysoft Limited is intended only for the personal use
of the recipient(s) named above.  The email and any files transmitted
with it are confidential to the intended recipient(s) and may be legally
privileged or contain proprietary and private information.  If you are
not an intended recipient, you may not review, copy or distribute this
message.  If received in error, please notify the sender and delete the
message from your system.

Any views or opinions expressed in this email and any files transmitted
with it are those of the author only and may not necessarily reflect the
views of Easysoft and do not create any legally binding rights or
obligations whatsoever. Unless otherwise pre-agreed by exchange of hard
copy documents signed by duly authorised representatives, contracts may
not be concluded on behalf of Easysoft by email.

Please note that neither Easysoft nor the sender accepts any
responsibility for any viruses and it is your responsibility to scan the
email and the attachments (if any).  All email received and sent by
Easysoft may be monitored to protect the business interests of Easysoft.