Re: Fwd: [unixODBC-support] PHP PDO unixODBC FreeTDS SQL Server text column size

2012/9/27 James K. Lowden <[email protected]>:
> On Wed, 26 Sep 2012 09:31:08 +1200
> Jochen Daum <[email protected]> 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.
>

I wrongly pushed a patch that fix some issue with characters and
bsqlodbc in Branch-0.91.

Wrongly just cause was not correctly tested, I reverted some changes.

Mainly:
- if you want just to get information from row you should get row
implementation descriptor, not create a new one as the new one would
have empty information
- SQLAllocHandle for descriptor wants a connection, not a statement,
this is the reason for the invalid handle returned
- SQLFetch can return SQL_NO_TOTAL (usually -4) if can't translate all
string to the check data[c].len > 0 can be false, I increased buffer
allocated for string however if string is empty the assert will still
raise. It would be better to handle correctly SQL_NO_TOTAL.

Frediano