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

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

am 12.10.2009 19:26:30 von Brigitte und Wolfgang Pasche

This is a multi-part message in MIME format.
--------------070104030005040603050006
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

-----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

Wolfgang Pasche
DigiTask GmbH
Hamburg/Haiger, Germany



P.S.: I also tried to use the other PostgreSQL ODBC driver, ODBCng.
Unfortunately, it was installed without errors, but didnt't wrote the
necessary entries into the Windows registry. I couldn't find registry
entries for this driver anywhere in the Internet, so I tried to contact
the developers via email, but didn't get an answer. Is this project
still under development or is it discontinued?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrTZrkACgkQUCcwxZk3KK1IbACfUKZbJ2nkwPLy6m/7GVG9 S7Lw
qEIAoKmZ0KTCf38ObEN6jR3STE8J7ENo
=4mKA
-----END PGP SIGNATURE-----


--------------070104030005040603050006
Content-Type: text/plain;
name="ODBC log with Escape error.txt"
Content-Disposition: inline;
filename="ODBC log with Escape error.txt"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by smtpa.mediabeam.com id n9CHQUgA023455

Example for correct escape sequence transformation (SELECT statement):



[25096-0.389]SC_recycle_statement: self=3D 01168FC0
[25096-0.390]PDATA_free_params: ENTER, self=3D01169164
[25096-0.391]Exec_with_parameters_resolved: copying statement params: trans=
_status=3D1, len=3D95, stmt=3D'select * from egstat_dbins( 100, 125, {d '20=
09-10-04'}, '15:36:46', 2000, 'ipadresse', 6, 0, 0)'
[25096-0.395] stmt_with_params =3D 'select * from egstat_dbins( 100, 125,=
'2009-10-04'::date , '15:36:46', 2000, 'ipadresse', 6, 0, 0)'
[25096-0.398]about to begin SC_execute
[25096-0.399] Sending SELECT statement on stmt=3D01168FC0, cursor_nam=
e=3D'SQL_CUR01168FC0' qflag=3D0,1
[25096-0.401]CC_send_query: conn=3D01163F68, query=3D'select * from egstat_=
dbins( 100, 125, '2009-10-04'::date , '15:36:46', 2000, 'ipadresse', 6, 0, =
0)'
[25096-0.407]send_query: done sending query 104bytes flushed


Example for wrong (missing) escape sequence transformation (CALL statement):



[22372-10.317]Exec_with_parameters_resolved: copying statement params: tran=
s_status=3D1, len=3D88, stmt=3D'{call egstat_dbins( 100, 125, {d '2009-10-1=
2'}, '13:28:26', 2000, 'ipadresse', 6, 0, 0)}'
[22372-10.321] stmt_with_params =3D 'SELECT * FROM egstat_dbins( 100, 125=
, d '2009-10-12', '13:28:26', 2000, 'ipadresse', 6, 0, 0)'
[22372-10.323]about to begin SC_execute
[22372-10.324] it's NOT a select statement: stmt=3D011620D0
[22372-10.326]CC_send_query: conn=3D01164F60, query=3D'SELECT * FROM egstat=
_dbins( 100, 125, d '2009-10-12', '13:28:26', 2000, 'ipadresse', 6, 0, 0)'
[22372-10.331]send_query: done sending query 100bytes flushed
[22372-10.332]in QR_Constructor
[22372-10.332]exit QR_Constructor
[22372-10.333]read -1, global_socket_buffersize=3D4096
[22372-10.334]Lasterror=3D10035
[22372-10.336]read 85, global_socket_buffersize=3D4096
[22372-10.337]send_query: got id =3D 'E'
[22372-10.338]send_query: 'E' - SFEHLER
[22372-10.340]send_query: 'E' - C42704
[22372-10.342]send_query: 'E' - MTyp =BBd=AB existiert nicht
[22372-10.345]send_query: 'E' - P40
[22372-10.346]send_query: 'E' - Fparse_type.c
[22372-10.349]send_query: 'E' - L200
[22372-10.351]send_query: 'E' - RtypenameType
[22372-10.353]read 6, global_socket_buffersize=3D4096
[22372-10.354]send_query: got id =3D 'Z'
[22372-10.355]SC_set_Result(11620d0, 1162a08)[22372-10.356]QResult: enter D=
ESTRUCTOR
[22372-10.359]STATEMENT ERROR: func=3DSC_execute, desc=3D'(null)', errnum=
=3D7, errmsg=3D'Error while executing the query'
[22372-10.391]CONN ERROR: func=3DSC_execute, desc=3D'(null)', errnum=3D110,=
errmsg=3D'FEHLER: Typ =BBd=AB existiert nicht'

--------------070104030005040603050006
Content-Type: application/octet-stream;
name="ODBC log with Escape error.txt.sig"
Content-Disposition: attachment;
filename="ODBC log with Escape error.txt.sig"
Content-Transfer-Encoding: base64

iEYEABECAAYFAkrTZrkACgkQUCcwxZk3KK19GACg4J3tju3GMZr6nJ4rDWLv
gkEldi0AnRU9uHiyQtRetZJ+K3zq0ClXhZeu

--------------070104030005040603050006
Content-Type: text/plain
Content-Disposition: inline
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable


--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

--------------070104030005040603050006--

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

am 19.10.2009 02:21:59 von Craig Ringer

Brigitte und Wolfgang Pasche wrote:

> 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

Yep, sounds like an ODBC driver bug for sure.

It might even be worth grabbing the ODBC driver sources to see if you
can spot the issue.

As it happens, the statement could be transformed correctly by
substituting 'DATE' for 'd'.

--
Craig Ringer

--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

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

am 19.10.2009 05:37:28 von Hiroshi Inoue

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


--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc