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

Re: Problem with psqlODBC and "call" (of Stored Procedures)

From: Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>
To: Brigitte und Wolfgang Pasche <pasche(dot)wolfgang(at)kabelmail(dot)de>
Cc: pgsql-odbc(at)postgresql(dot)org
Subject: Re: Problem with psqlODBC and "call" (of Stored Procedures)
Date: 2009-10-19 03:37:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-odbc
Brigitte und Wolfgang Pasche wrote:
> Hash: SHA1
> Hi,
> I am working since March 2009 for my actual company. The software we
> make is based on Databases. Our normal environment is a database server
> (actually Informix) on Linux or Unix and database client software on
> Windows Server 2003 or Windows XP. Since at many customer sites the
> single DB server is overloaded, we need to split our DBs to more than
> one server. Because most of our customers don't have much money, we
> decided to move our applications to PostgreSQL. For this port I am
> responsible. Nearly anything worked very well, I am using PostgreSQL
> 8.3.7 on Linux and psqlODBC on Windows XP (all of our client
> applications are written in C++ with MS Visual Studio 2005 as IDE). The
> decision for ODBC had been done because of portability and independence
> of the programming language. Also because of portability all date and
> time literals sent to the ODBC driver are in the form of the official
> ODBC escape clauses (for example "{d '2009-10-01'}" for the first of
> October, 2009).
> Now my problem:
> If I use this escape strings in "SELECT" statements, anything works
> well. But nearly 95 percent of our DB statements ere stored procedure
> calls; we use the ODBC standard for this in the form: "{call myproc
> (par1, par2, par3, ..., parn)}". In this case, since PostgreSQL don't
> know a call statement, the ODBC driver correctly transform it into a
> SELECT statement. Unfortunately, the procedure parameter (datatype date)
> in the escaped form is transformed removing only the curly braces and
> leaving the rest untouched instead of transforming it (in a second
> step??) to the correct form. This of course leads to nonsense and
> results in an error message.
> My personal impression is, that this is a bug in the ODBC driver, but of
> course I'd like to hear your opinion. The only workaround for us would
> be to change all of our application software and use the SELECT form for
> PostgreSQL calls, but this would be a lot of work and would reduce the
> portability of our software. So I hope you can fix this in the driver.
> I attached a part of two ODBC log files (the "mylog_nnnn.log versions)
> so you can see the problem. The statement string delivered from the
> application is logged under: "Exec_with_parameters_resolved", while the
> transformed version is logged in the nect line as: "stmt_with_params".
> Expecting to hear from you and
> with kind regards

Could you Please try the drivers on testing for 8.4.0101 at

Hiroshi Inoue

In response to

pgsql-odbc by date

Next:From: Hiroshi InoueDate: 2009-10-19 04:01:06
Subject: Re: Postgres inserts null value for parameterized statement
Previous:From: Craig RingerDate: 2009-10-19 00:21:59
Subject: Re: Problem with psqlODBC and "call" (of Stored Procedures)

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