Skip site navigation (1) Skip section navigation (2)


From: Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>
To: Marten Lehmann <lehmann(at)cnm(dot)de>
Cc: pgsql-odbc(at)postgresql(dot)org
Subject: Re: SQLDescribeParam / SUPPORT_DESCRIBE_PARAM
Date: 2011-11-09 03:48:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-odbc
Hi Marten,

(2011/11/09 10:42), Marten Lehmann wrote:
> Hello,
> 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
> 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.

Inoue, Hiroshi

> Kind regards
> Marten Lehmann

In response to


pgsql-odbc by date

Next:From: Hiroshi InoueDate: 2011-11-09 03:51:50
Subject: Re: Fetch absolute returns OK when fetching a nonexistent row
Previous:From: Marten LehmannDate: 2011-11-09 01:42:52

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group