Re: Fwd: [unixODBC-support] PHP PDO unixODBC FreeTDS SQL Server text column size
"James K. Lowden" <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <[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. --jkl