Skip to Content.
Sympa Menu

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

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Jochen Daum <jd AT automatem.co.nz>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Fwd: [unixODBC-support] PHP PDO unixODBC FreeTDS SQL Server text column size
  • Date: Thu, 27 Sep 2012 15:55:06 +1200

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




Archive powered by MHonArc 2.6.24.

Top of Page