Re: Statement has been closed (only in Windows) - Mailing list pgsql-jdbc

From Carlos Correia
Subject Re: Statement has been closed (only in Windows)
Date
Msg-id 43E928A8.3080408@m16e.com
Whole thread Raw
In response to Re: Statement has been closed (only in Windows)  (pedro farinha <pedro@geotaxi.com>)
Responses Re: Statement has been closed (only in Windows)  (Nelson Arape <narape@ica.luz.ve>)
List pgsql-jdbc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

pedro farinha escreveu:
| Hi Carlos, if you're problem is solved what is the question?
| if you worry about creating a lot of statements, don't. But make sure
| you close them after use. Also the resultSet if any. Not a big brain on
| this end, but why would you want to keep the statement open?

Well, why not? It's a fat client, It establishes a connection at
application start up and closes it once the app finishes... what's the
problem about keeping the same statement (it's been working like that in
a production environment for years in Linux)?

Anyway, after I made the workaround I mentioned in a previous post
(creating a new statement per request), began getting errors in prepared
statements, which I'll try to reproduce (tomorrow?) and published them here.

The questions now are:
- - How stable is PostreSQL on a Windows environment, by now?

- - Are there any known problems with transactions, prepared statements or
storeed procedures in a Windows environment?

Thanks,

Carlos
- --
MEMÓRIA PERSISTENTE, Lda.
Tel.: 219 291 591 - GSM:  967 511 762
e-mail: geral@m16e.com - URL: http://www.m16e.com
AIM: m16e - ICQ: 257488263 - Jabber: m16e@amessage.de
Skype.com username (VoIP): m16e.com
GnuPG: wwwkeys.eu.pgp.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD6Sio90uzwjA1SJURAu43AJ9t6YzRnncHCBbxsdbe111jFWVzWQCgo3T1
fnnTxAl/v+irDbYrRyq2Xt0=
=/OV6
-----END PGP SIGNATURE-----

pgsql-jdbc by date:

Previous
From: Matthew Bellew
Date:
Subject: Re: Inconsistent casting with literal vs parameter
Next
From: Matthew Bellew
Date:
Subject: Re: Inconsistent casting with literal vs parameter