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

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема Re: Problem with psqlODBC and "call" (of Stored Procedures)
Дата
Msg-id 4ADBDEF8.3080509@tpf.co.jp
обсуждение исходный текст
Ответ на Problem with psqlODBC and "call" (of Stored Procedures)  (Brigitte und Wolfgang Pasche <pasche.wolfgang@kabelmail.de>)
Список pgsql-odbc
Brigitte und Wolfgang Pasche wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
   http://www.geocities.jp/inocchichichi/psqlodbc/index.html
?

regards,
Hiroshi Inoue


В списке pgsql-odbc по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Problem with psqlODBC and "call" (of Stored Procedures)
Следующее
От: Hiroshi Inoue
Дата:
Сообщение: Re: Postgres inserts null value for parameterized statement