FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

On Wed, 26 Sep 2012 09:31:08 +1200
Jochen Daum <jd AT automatem.co.nz> wrote:

> bsqlodbc -v -Uwebsite -Ppassword -SEIS -DExportInformationSystem -o
> output -e error -i Attachment.sql
> 
> returns
> 
> output: empty
> error:
> bsqlodbc:273: Verbose operation enabled
> bsqlodbc:366: Query:
>       set textsize 10000000
>       select attaRefTable from [Attachment] where ([Attachment].
> [attaId] = 10239) Metadata
> col     name                            type value  type name
>  size    varies
> ------  ------------------------------  ----------  ------------------
>  ------  ------
> bsqlodbc: error -2: SQLAllocHandle: invalid handle: failed
> 
> freetds.log attached.

Thanks, that's enough that I've run out of questions.  Unfortunately,
I'm fresh out of answers, too.  :-(

The error is either in bsqlodbc or in the driver.  If unixODBC's isql
can process the query, it's a bug either in bsqlodbc.  Otherwise
there's a problem with SQLDescribeCol. Let's see what we know:

1.  bsqlodbc -v tried to print the metadata.  To do that it called
SQLDescribeCol().  That's the last line of your TDSDUMP.  It failed:
bsqlodbc was unable to print any metadata, even though the metadata had
arrived from the server,

>       colname = attaRefTable (12 bytes)
>       type = 39 (varchar)
>       server's type = 167 (xvarchar)
>       column_varint_size = 2
>       column_size = 30 (30 on server)

(That doesn't look like the same column as in your last message
which was "attaContent", type text.)

2.  The problem went undetected by bsqlodbc, which means SQLDescribeCol
didn't return an error.  If it had, bsqlodbc would have noticed, and
exited immediately, on line 544.  Perhaps bad inputs were passed to
SQLDescribeCol.  If so, it failed to report that fact.  

3.  bsqlodbc continued on to SQLAllocHandle(), which rejected the
hstmt parameter.  At that point bsqlodbc quit.  This is not captured in
the log because in odbc.c, _SQLAllocDesc() tests the hdbc parameter
before logging the call.  

This looks broken to me: SQLAllocHandle() is passed SQLHSTMT, a
statement handle, but passes it to _SQLAllocDesc(), which tests its
validity as SQLHDBC, a connection handle, with ODBC_ENTER_HDBC.
Perhaps Frediano can shed some light here.  I think parameter should be
a statement handle and the test should be ODBC_ENTER_HSTMT.  But this
code is undoubtedly called frequently and surely works?  

In sum, 

There seem to be problems in error-checking in SQLDescribeCol and maybe
_SQLAllocDesc.  There might be a bug in bsqlodbc triggering all that. 

If there is a problem in the driver, it might explain what you're
seeing in PHP.  

HTH.  

--jkl