Doesn't look like mine. You have an underlying ResultSet instance in the wrapper class (DelegatingResultSet) because the wrapper method successfully called Oracle's method. I don't have the underlying result set in my case, I get a null pointer exception from the wrapper class. Did you check the number of columns returned within the result set before looking at rs.getString(1)? This is a long shot given your error, but you may want to use the getMetaData() method on the result set to get the ResultSetMetaData object, check for null and then call its getColumnCount() method to make sure it is there (you should have gotten a null pointer exception if this was the case though). Also, this isn't likely to be the problem if you can process multiple rows within the result set before you crash, but it could be. Good luck! Takeshi L Toyohara <[EMAIL PROTECTED]> wrote:hmmm...that sounds promising. in fact, we are getting some errors about the Connection being closed as well, but the exhausted result set errors are much more frequent. here is my stack trace.
cheers, t WARN [HttpProcessor[8080][2]] [ScheduleMgr.java:411] com.cauldron.mermaid.sched ule.ScheduleMgr - Unable to process ResultSet. java.sql.SQLException: Exhausted Resultset at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134) at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:179) at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:269) at oracle.jdbc.driver.OracleStatement.prepare_for_new_get(OracleStatemen t.java:3195) at oracle.jdbc.driver.OracleStatement.getStringValue(OracleStatement.jav a:3444) at oracle.jdbc.driver.OracleResultSetImpl.getString(OracleResultSetImpl. java:434) at org.apache.commons.dbcp.DelegatingResultSet.getString(DelegatingResul tSet.java:137) at com.cauldron.mermaid.schedule.ScheduleMgr.loadScheduleIntervals(Sched uleMgr.java:358) -----Original Message----- From: Stephen Westbom [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 14, 2003 8:25 PM To: Jakarta Commons Users List; [EMAIL PROTECTED] Subject: Re: commons dbcp - random exhausted resultsets Can you get a stack trace? There are two bugs with multiple result set handling in the result set wrapper class within the dbcp package in the next() and close() wrapper methods. I fixed them on my sandbox and sent them to the commons package owner email address describing the problem. The bug I get is a null pointer exception in mine, not an exhausted error, but this was using Sybase's ResultSet and CallableStatement implementations, not Oracle's. The same problem could be manifested differently with Oracle. Thanks Takeshi L Toyohara wrote:hey all, just wondering if anyone has had a similar issue with getting the ol SQLException: Exhausted ResultSet, even though i have a while(rs.next()). running tomcat4 (4.0 and 4.1) oracle 9i using the commons dbcp as the connection pool as described in the tomcat conn pool FAQ classes12.zip (oracle 9i thin driver) here's the code snippet thats barfing. there is not a pattern to how many times through the while loop it goes before it fails and spits up the SQLException. anyone have any thoughts on the matter? some more info: i printed out the value of rs.next() and its "true" right before i get the Exhausted ResultSet exception. fairly interesting... thanks in advance t ---------- rs = DBU.executeQuery(SQL, args); while (rs.next()) { ... currIntID = rs.getString(1); // this statement throws an exception after N(unknown) // times through the while() loop ... } ... rs.close(),ps.close(),conn.close(),etc. ------------ -- Takeshi L Toyohara Cauldron Solutions Solutions Developer 212.696.1600x20 (office) 212.696.2336 (fax) -- To unsubscribe, e-mail: For additional commands, e-mail: --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now -- To unsubscribe, e-mail: For additional commands, e-mail: --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now
