Re: psqlodbc and SQLFetch after SQLTables gives SQL_NO_DATA_FOUND

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Giuliano Gavazzi <dev+pgsql(at)humph(dot)com>
Cc: pgsql-odbc(at)postgresql(dot)org
Subject: Re: psqlodbc and SQLFetch after SQLTables gives SQL_NO_DATA_FOUND
Date: 2003-02-10 07:02:05
Message-ID: 3E474E6D.F2D7FAFC@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

Giuliano Gavazzi wrote:
>
> Dear list,
>
> I posted some time ago about a problem with retrieving table in
> MSQuery on MacOSX using postgres 3.7.1 and psqlodbc-7.2.5 with
> iODBC (iODBC-SDK-3.5.3).
>
> At the time I found, by snooping the TCP stream, that the SQLTables
> function, that must be used by MSQuery to retrieve the table list,
> did indeed return the tables, but for some reason MSQuery was unable
> to get this data.
>
> Now I have enabled tracing and found where the failure is. Apparently
> MSQ uses SQLFetch just after SQLTables to get the table list, this
> SQLFetch fails by returning SQL_NO_DATA_FOUND. Here I have two
> snippets from the traces of MSQ retrieving tables first using
> OpenLink Postgres Lite driver (that succeeds) and then using psqlodbc
> (that fails):
>
> 1) openlink driver:
>
> iODBC[Microsoft Query] ThID:A0000DEC ENTER SQLTables
>
> iODBC[Microsoft Query] ThID:A0000DEC EXIT SQLTables with return
> code 0 (SQL_SUCCESS)
>
> Microsoft Query ThID:A0000DEC EXIT SQLTables with return code 0
> (SQL_SUCCESS)
> HSTMT 0x01619a00
> CHAR* 00000000 "..."
> SMALLINT -3536
> CHAR* 00000000 "..."
> SMALLINT -18992
> CHAR* 00000000 "..."
> SMALLINT 15056
> CHAR* 0x001c3fd8 "Table"

Hmm, if it is "TABLE", it seems to work.
OK I would change the driver to be insenitive about
it.

regards,
Hiroshi Inoue
http://www.geocities.jp/inocchichichi/psqlodbc/

In response to

Responses

Browse pgsql-odbc by date

  From Date Subject
Next Message Giuliano Gavazzi 2003-02-10 14:33:48 Re: psqlodbc and SQLFetch after SQLTables gives
Previous Message Hiroshi Inoue 2003-02-10 06:59:28 Re: ConnInfo assumes signed char