JR <[email protected]> writes: > I checked out and built the 10.4 branch and am seeing inconsistent > results when requesting the runtime statistics for a prepared > statement. I've tracked it down to the "isTopResultSet" check in the > NoPutResultSetImpl.close() method. It seems that "isTopResultSet" > doesn't get changed for the second (and subsequent) executions of > insert and delete statements. This causes the runtime statistics > update logic to be skipped and will return the stats for the wrong > statement.
Hi, I'm wondering if the problem you're seeing is a side-effect of DERBY-827. Before, a new result set would be created each time a statement was re-executed, so all the flags were implicitly reset on re-execution. Now, the result set objects are reused (which significantly improved the performance) and that means that variables must be reset explicitly between executions. DERBY-827 was fixed in 10.3.1.4, and I actually see the behaviour you're describing in that version, whereas 10.2.2.0 behaves as expected. I'll file a bug report. Thanks, -- Knut Anders
