Hi John,
We've been seeing an intermittent failure with this test with some of the jvms we run against on a slow machine.
It appears the test is not 'tight' enough to always pass on slower machines - sometimes one of the queries results in a table scan, sometimes an index scan.
I can't right now remember if there is a JIRA_CASE for it. If not, it wouldn't harm.
There was a bug filed at one point for the summary calculation being wrong, but it looks like it was not fixed entirely - I think I saw that the sub-suites seem to get it right, but derbyall doesn't?
I wanted to check into this, but never got around to it. A new bug would be good as a reminder...
Myrna
On 6/28/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I am running on a test build of a JVM (not a formal JVM release) and I would like to get someone's opinion as to whether this test failure is due to a bug in the JVM.
Can Derby's behaviour (e.g. optimizations etc) differ based upon the speed of the machine it is running on (therefore affecting test output), or will it always operate identically, no matter the hardware? The reason I ask is that I ran the tests at a low priority on a busy system.
I also noticed that the test report said 0% fail even though one test failed.
Let me know if you want JIRA issues raised.
All derbylang tests passed on Windows XP.
Thanks,
John
