FreeTDS Development Group

[Jochen Daum <jd AT automatem.co.nz>]

Thanks,

>> 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.)

No, I've changed it to a varchar column, which doesn't work either.
int columns work.

> 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.
>
I've used Ubuntu 12.04 packages, shall I compile freetds from source maybe?

Kind Regards,

Jochen