Wasn't there some other code in the finally clause which could throw another SQLException? This would explain why some code got executed while the rest did not. By the way, the javadoc says:
close public void close() throws SQLExceptionReleases a Connection's database and JDBC resources immediately instead of waiting for them to be automatically released. Note: A Connection is automatically closed when it is garbage collected. Certain fatal errors also result in a closed Connection. Hmmm, so it cleans up after itself if there is no statement open (at least in theory), but everywhere I look people recommend cleaning up programmatically. I am not happy with jdbc anyway, it's hard to avoid repetitive code, because you loose the ResultSet as soon as you close the statement, making it impossible to call a method which just interacts the database and then lets you do what you want with the resultset while the connection is free for another access (with the exception of SELECT of course). One could make a copy of the ResultSet, but if you have 10,000+ rows you need to process, this becomes a performance nightmare. If anybody has a better suggestion, I'd be eager to listen! Just wrote a few 1000 lines of sql code, very boring ... -----Original Message----- From: Curt Smith [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 1:33 PM To: Orion-Interest Subject: Re: JDBC try/catch Pitfall ***MUST READ*** try { ... return; } catch () {} finally { // must always come here per the Java VM spec // else it's a bug // Not calling the instance obj ref methods is a serious bug IMHO } To me this looks like a bug not an odd side effect. What's your operating environment? Linux? curt