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 по дате отправления: