(2011/11/09 10:42), Marten Lehmann wrote:
> I noticed that unixODBC logs IM001 SQL_ERRORs for SQLDescribeParam in
> its tracefile. Actually, I first noticed the problem when I tried to use
> a prepared statement in PHP 5.3.8 with a PostgreSQL 9.1 database and I
> got error messages at odbc_execute() due to the SQLDescribeParam error.
> First I thought that the problem is in PHPs ODBC extension because it
> worked fine back in PHP-5.3.3. But digging into the sources of PHP I
> found out, that the return value of SQLDescribeParam simply wasn't
> validated before 5.3.5 (and there as no 5.3.4 release), but it returned
> an IM001 SQL_ERROR ever since.
> So following the chain I looked at the source of psqlodbc and noticed,
> that the library is prepared for a database connection that supports
> SQLDescribeParam and this is verified by SUPPORT_DESCRIBE_PARAM().
> But what does it depend on, whether the connection supports it? psqlodbc
> is for PostgreSQL only. I built the latest PostgreSQL library, compiled
> the latest psqlodbc against it and SQLDescribeParam still threw the
> IM001 SQL_ERROR.
> As a quick fix just created a patch for PHP for my internal use, which
> removes checking of the return values of SQLDescribeParam. But that
> seems very odd. I'd really like to understand what's behind this issue.
Please check the *Server side prepare* option of your datasource or
add UseServerSidePrepare=1 to your connection string.
> Kind regards
> Marten Lehmann
In response to
pgsql-odbc by date
|Next:||From: Hiroshi Inoue||Date: 2011-11-09 03:51:50|
|Subject: Re: Fetch absolute returns OK when fetching a nonexistent
|Previous:||From: Marten Lehmann||Date: 2011-11-09 01:42:52|
|Subject: SQLDescribeParam / SUPPORT_DESCRIBE_PARAM|