You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Bernt M. Johnsen" <Be...@Sun.COM> on 2005/05/26 23:26:14 UTC

DerbyNetClient/lang/updatableResultSet fails

When running derbyall, DerbyNetClient/lang/updatableResultSet fails
the following way:

*** Start: updatableResultSet jdk1.4.2_02 DerbyNetClient 2005-05-26 23:12:55 ***
Initialize for framework: DerbyNetClient
java -ms16777216 -mx33554432 -Dderby.system.home=/export/home/tmp/Derby/test/Der byNetClient/updatableResultSet -Djava.security.manager -Djava.security.policy=/e xport/home/tmp/Derby/test/nwsvr.policy -Dcsinfo.codebase=/export/home/tmp/Derby/ trunk/jars/sane -Dcsinfo.serverhost=localhost -Dcsinfo.trustedhost=localhost org .apache.derby.drda.NetworkServerControl start
Attempt to shutdown framework: DerbyNetClient
310 del
< Got expected exception Cursor 'SQL_CURLH000C52' is not on a row.
310a310
> Got expected exception Cursor 'SQL_CURLH000C51' is not on a row.
317 del
<       SQL_CURLH000C55
317a317
>       SQL_CURLH000C54
Test Failed.
*** End:   updatableResultSet jdk1.4.2_02 DerbyNetClient 2005-05-26 23:13:22 ***

(Same error with 1.5 and 1.3)

I'm running with Linux 2.6.11. What I find strange, is that when I
inspect the test failures in
http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-178249.html
I see that the same test fails in the same way on all platforms,
with the exception of the test run on a Linux 2.4.19 and jdk1.4.2_08

Comment anynone?
-- 
Bernt Marius Johnsen, Database Technology Group, 
Sun Microsystems, Trondheim, Norway

Re: DerbyNetClient/lang/updatableResultSet fails

Posted by David Van Couvering <da...@vancouvering.com>.
Yes, I remember getting this problem too.

David

Bernt M. Johnsen wrote:

> When running derbyall, DerbyNetClient/lang/updatableResultSet fails
> the following way:
> 
> *** Start: updatableResultSet jdk1.4.2_02 DerbyNetClient 2005-05-26 23:12:55 ***
> Initialize for framework: DerbyNetClient
> java -ms16777216 -mx33554432 -Dderby.system.home=/export/home/tmp/Derby/test/Der byNetClient/updatableResultSet -Djava.security.manager -Djava.security.policy=/e xport/home/tmp/Derby/test/nwsvr.policy -Dcsinfo.codebase=/export/home/tmp/Derby/ trunk/jars/sane -Dcsinfo.serverhost=localhost -Dcsinfo.trustedhost=localhost org .apache.derby.drda.NetworkServerControl start
> Attempt to shutdown framework: DerbyNetClient
> 310 del
> < Got expected exception Cursor 'SQL_CURLH000C52' is not on a row.
> 310a310
> 
>>Got expected exception Cursor 'SQL_CURLH000C51' is not on a row.
> 
> 317 del
> <       SQL_CURLH000C55
> 317a317
> 
>>      SQL_CURLH000C54
> 
> Test Failed.
> *** End:   updatableResultSet jdk1.4.2_02 DerbyNetClient 2005-05-26 23:13:22 ***
> 
> (Same error with 1.5 and 1.3)
> 
> I'm running with Linux 2.6.11. What I find strange, is that when I
> inspect the test failures in
> http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-178249.html
> I see that the same test fails in the same way on all platforms,
> with the exception of the test run on a Linux 2.4.19 and jdk1.4.2_08
> 
> Comment anynone?

Re: DerbyNetClient/lang/updatableResultSet fails

Posted by Sunitha Kambhampati <ks...@gmail.com>.
I am also seeing the same diff... if I run this test separately using 
RunTest.  ( windows,  sun jdk 1.4.2_07-b05)

But in one of my derbyall runs on my windows machine, I am getting a 
different diff with respect to the cursor names ( the number in the end 
differs).   The strange thing is it seemed to pass ok on one other 
(win2k)  machine though.

Thanks,
Sunitha.

Bernt M. Johnsen wrote:

>When running derbyall, DerbyNetClient/lang/updatableResultSet fails
>the following way:
>
>*** Start: updatableResultSet jdk1.4.2_02 DerbyNetClient 2005-05-26 23:12:55 ***
>Initialize for framework: DerbyNetClient
>java -ms16777216 -mx33554432 -Dderby.system.home=/export/home/tmp/Derby/test/Der byNetClient/updatableResultSet -Djava.security.manager -Djava.security.policy=/e xport/home/tmp/Derby/test/nwsvr.policy -Dcsinfo.codebase=/export/home/tmp/Derby/ trunk/jars/sane -Dcsinfo.serverhost=localhost -Dcsinfo.trustedhost=localhost org .apache.derby.drda.NetworkServerControl start
>Attempt to shutdown framework: DerbyNetClient
>310 del
>< Got expected exception Cursor 'SQL_CURLH000C52' is not on a row.
>310a310
>  
>
>>Got expected exception Cursor 'SQL_CURLH000C51' is not on a row.
>>    
>>
>317 del
><       SQL_CURLH000C55
>317a317
>  
>
>>      SQL_CURLH000C54
>>    
>>
>Test Failed.
>*** End:   updatableResultSet jdk1.4.2_02 DerbyNetClient 2005-05-26 23:13:22 ***
>
>(Same error with 1.5 and 1.3)
>
>I'm running with Linux 2.6.11. What I find strange, is that when I
>inspect the test failures in
>http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-178249.html
>I see that the same test fails in the same way on all platforms,
>with the exception of the test run on a Linux 2.4.19 and jdk1.4.2_08
>
>Comment anynone?
>  
>


Re: DerbyNetClient/lang/updatableResultSet fails

Posted by Myrna van Lunteren <m....@gmail.com>.
Without looking at the test or any -recent- changes, I'm giving this as my 2 
cents:
 If that cursorname is generated, and if a generated cursorname does not 
need to be identical in the same scenario on all system/jvm combinations, 
then the name should get out of the output.
i.e. either in the test it should not print the cursor names, or, if that is 
not feasible, it should get masked by adding appropriate lines to 
updatableResultSet_sed.properties.
 Myrna

 On 5/26/05, Bernt M. Johnsen <Be...@sun.com> wrote: 
> 
> When running derbyall, DerbyNetClient/lang/updatableResultSet fails
> the following way:
> 
> *** Start: updatableResultSet jdk1.4.2_02 DerbyNetClient 2005-05-26 
> 23:12:55 ***
> Initialize for framework: DerbyNetClient
> java -ms16777216 -mx33554432 -
> Dderby.system.home=/export/home/tmp/Derby/test/DerbyNetClient/updatableResultSet -
> Djava.security.manager -Djava.security.policy=/export/home/tmp/Derby/test/nwsvr.policy -
> Dcsinfo.codebase=/export/home/tmp/Derby/ trunk/jars/sane -
> Dcsinfo.serverhost=localhost -Dcsinfo.trustedhost=localhost org 
> .apache.derby.drda.NetworkServerControl start
> Attempt to shutdown framework: DerbyNetClient
> 310 del
> < Got expected exception Cursor 'SQL_CURLH000C52' is not on a row.
> 310a310
> > Got expected exception Cursor 'SQL_CURLH000C51' is not on a row.
> 317 del
> < SQL_CURLH000C55
> 317a317
> > SQL_CURLH000C54
> Test Failed.
> *** End: updatableResultSet jdk1.4.2_02 DerbyNetClient 2005-05-26 23:13:22 
> ***
> 
> (Same error with 1.5 and 1.3)
> 
> I'm running with Linux 2.6.11. What I find strange, is that when I
> inspect the test failures in
> 
> http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-178249.html
> I see that the same test fails in the same way on all platforms,
> with the exception of the test run on a Linux 2.4.19 and jdk1.4.2_08
> 
> Comment anynone?
> --
> Bernt Marius Johnsen, Database Technology Group,
> Sun Microsystems, Trondheim, Norway
>

Re: DerbyNetClient/lang/updatableResultSet fails

Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
Cool. Thanks!

David Van Couvering wrote:

> Kathey already submitted a patch I made to fix this where I filter out
> the cursor name.  So this failure should no longer occur.
>
> David
>
> Satheesh Bandaram wrote:
>
>> I was trying to update some other master outputs, following
>> Tomohito's change. Looks like this got changed along with others. I
>> can either revert this or if it has already been done, then ok.
>>
>> Satheesh
>>
>> Mamta Satoor wrote:
>>
>>> Hi,
>>>  
>>> I am trying to understand the reasons behind updatableResultset test
>>> failure when using DerbyNetClient. Following is what I have found so
>>> far.
>>>  
>>> Satheesh made a checkin on May 25th (revision 178519) to the master
>>> file DerbyNetClient/updatableResultSet.out which was as follows
>>> +++
>>> incubator/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/updatableResultSet.out
>>> Wed May 25 12:39:51 2005
>>> @@ -307,14 +307,14 @@
>>>  delete using first resultset
>>>  attempt to send deleteRow on the same row through a different
>>> resultset should throw an exception
>>>  SQL State : XCL08
>>> -Got expected exception Cursor 'SQL_CURLH000C51' is not on a row.
>>> +Got expected exception Cursor 'SQL_CURLH000C52' is not on a row.
>>>  Move to next row in the 2nd resultset and then delete using the
>>> second resultset
>>>  Positive Test11 - setting the fetch size to > 1 will be ignored by
>>> updatable resultset. Same as updatable cursors
>>>  Notice the Fetch Size in run time statistics output.
>>>  1
>>>  -----
>>>  Statement Name:
>>> -       SQL_CURLH000C54
>>> +       SQL_CURLH000C55
>>>  Statement Text:
>>>        SELECT * FROM t1 FOR UPDATE of c1
>>>  Parse Time: 0
>>>
>>> On May 26th, Bernt reported a diff which is reverse of master update
>>> done by Satheesh. Checkin from today (revision 179592) submitted by
>>> David seems to bring the master back to the state prior to
>>> Satheesh's checkin.   
>>> Also, Bernt, I looked at
>>> http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-178249.html
>>> <http://www.multinet.no/%7Esolberg/public/Apache/Derby/Limited/testSummary-178249.html>
>>> and the reason you didn't see the failure on Linux 2.4.19 and
>>> jdk1.4.2_08 I think is because the test never got run on that
>>> machine for some reason. In the list of tests that ran as part of
>>> derbynetclientmats on Linux 2.4.19 and jdk1.4.2_08, I don't see
>>> updatableResultset test in there. Let me know if I have missed
>>> anything. But if I am right, then we don't need
>>> updatableResultSet_sed.properties since we should get same cursor
>>> name irrespective of different platforms. The only question I have
>>> is why did Satheesh need to change the master? I am running with
>>> classes and maybe there is something that shows up only with the jar
>>> files. Satheesh, please let me know if there is an environment that
>>> I have not tested which required the master update.
>>>  
>>> thanks,
>>> Mamta
>>>  
>>>
>>> On 5/26/05, *Bernt M. Johnsen* <Bernt.Johnsen@sun.com
>>> <ma...@sun.com>> wrote:
>>>
>>>
>>>     When running derbyall, DerbyNetClient/lang/updatableResultSet fails
>>>     the following way:
>>>
>>>     *** Start: updatableResultSet jdk1.4.2_02 DerbyNetClient
>>>     2005-05-26 23:12:55 ***
>>>     Initialize for framework: DerbyNetClient
>>>     java -ms16777216 -mx33554432
>>>     -Dderby.system.home=/export/home/tmp/Derby/test/Der
>>>     byNetClient/updatableResultSet -Djava.security.manager
>>>     -Djava.security.policy=/e xport/home/tmp/Derby/test/nwsvr.policy
>>>     -Dcsinfo.codebase=/export/home/tmp/Derby/ trunk/jars/sane
>>>     -Dcsinfo.serverhost=localhost -Dcsinfo.trustedhost=localhost org
>>>     .apache.derby.drda.NetworkServerControl start
>>>     Attempt to shutdown framework: DerbyNetClient
>>>     310 del
>>>     < Got expected exception Cursor 'SQL_CURLH000C52' is not on a row.
>>>     310a310
>>>     > Got expected exception Cursor 'SQL_CURLH000C51' is not on a row.
>>>     317 del
>>>     <       SQL_CURLH000C55
>>>     317a317
>>>     >       SQL_CURLH000C54
>>>     Test Failed.
>>>     *** End:   updatableResultSet jdk1.4.2_02 DerbyNetClient
>>>     2005-05-26 23:13:22 ***
>>>
>>>     (Same error with 1.5 and 1.3)
>>>
>>>     I'm running with Linux 2.6.11. What I find strange, is that when I
>>>     inspect the test failures in
>>>    
>>> http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-178249.html
>>>
>>>    
>>> <http://www.multinet.no/%7Esolberg/public/Apache/Derby/Limited/testSummary-178249.html>
>>>
>>>     I see that the same test fails in the same way on all platforms,
>>>     with the exception of the test run on a Linux 2.4.19 and
>>> jdk1.4.2_08
>>>
>>>     Comment anynone?
>>>     --
>>>     Bernt Marius Johnsen, Database Technology Group,
>>>     Sun Microsystems, Trondheim, Norway
>>>
>>>
>
>
>


Re: DerbyNetClient/lang/updatableResultSet fails

Posted by David Van Couvering <Da...@Sun.COM>.
Kathey already submitted a patch I made to fix this where I filter out 
the cursor name.  So this failure should no longer occur.

David

Satheesh Bandaram wrote:

> I was trying to update some other master outputs, following Tomohito's 
> change. Looks like this got changed along with others. I can either 
> revert this or if it has already been done, then ok.
> 
> Satheesh
> 
> Mamta Satoor wrote:
> 
>> Hi,
>>  
>> I am trying to understand the reasons behind 
>> updatableResultset test failure when using DerbyNetClient. Following 
>> is what I have found so far.
>>  
>> Satheesh made a checkin on May 25th (revision 178519) to the master 
>> file DerbyNetClient/updatableResultSet.out which was as follows
>> +++ 
>> incubator/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/updatableResultSet.out 
>> Wed May 25 12:39:51 2005
>> @@ -307,14 +307,14 @@
>>  delete using first resultset
>>  attempt to send deleteRow on the same row through a different 
>> resultset should throw an exception
>>  SQL State : XCL08
>> -Got expected exception Cursor 'SQL_CURLH000C51' is not on a row.
>> +Got expected exception Cursor 'SQL_CURLH000C52' is not on a row.
>>  Move to next row in the 2nd resultset and then delete using the 
>> second resultset
>>  Positive Test11 - setting the fetch size to > 1 will be ignored by 
>> updatable resultset. Same as updatable cursors
>>  Notice the Fetch Size in run time statistics output.
>>  1
>>  -----
>>  Statement Name:
>> -       SQL_CURLH000C54
>> +       SQL_CURLH000C55
>>  Statement Text:
>>        SELECT * FROM t1 FOR UPDATE of c1
>>  Parse Time: 0
>>
>> On May 26th, Bernt reported a diff which is reverse of master update 
>> done by Satheesh. Checkin from today (revision 179592) submitted by 
>> David seems to bring the master back to the state prior to Satheesh's 
>> checkin.  
>>  
>> Also, Bernt, I looked at 
>> http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-178249.html 
>> <http://www.multinet.no/%7Esolberg/public/Apache/Derby/Limited/testSummary-178249.html> and 
>> the reason you didn't see the failure on Linux 2.4.19 and jdk1.4.2_08 
>> I think is because the test never got run on that machine for some 
>> reason. In the list of tests that ran as part of derbynetclientmats on 
>> Linux 2.4.19 and jdk1.4.2_08, I don't see updatableResultset test in 
>> there. Let me know if I have missed anything. But if I am right, then 
>> we don't need updatableResultSet_sed.properties since we should get 
>> same cursor name irrespective of different platforms. 
>> The only question I have is why did Satheesh need to change the 
>> master? I am running with classes and maybe there is something that 
>> shows up only with the jar files. Satheesh, please let me know if 
>> there is an environment that I have not tested which required the 
>> master update.
>>  
>> thanks,
>> Mamta
>>  
>>
>>On 5/26/05, *Bernt M. Johnsen* <Bernt.Johnsen@sun.com <ma...@sun.com>> wrote:
>> 
>>
>>     When running derbyall, DerbyNetClient/lang/updatableResultSet fails
>>     the following way:
>>
>>     *** Start: updatableResultSet jdk1.4.2_02 DerbyNetClient
>>     2005-05-26 23:12:55 ***
>>     Initialize for framework: DerbyNetClient
>>     java -ms16777216 -mx33554432
>>     -Dderby.system.home=/export/home/tmp/Derby/test/Der
>>     byNetClient/updatableResultSet -Djava.security.manager
>>     -Djava.security.policy=/e xport/home/tmp/Derby/test/nwsvr.policy
>>     -Dcsinfo.codebase=/export/home/tmp/Derby/ trunk/jars/sane
>>     -Dcsinfo.serverhost=localhost -Dcsinfo.trustedhost=localhost org
>>     .apache.derby.drda.NetworkServerControl start
>>     Attempt to shutdown framework: DerbyNetClient
>>     310 del
>>     < Got expected exception Cursor 'SQL_CURLH000C52' is not on a row.
>>     310a310
>>     > Got expected exception Cursor 'SQL_CURLH000C51' is not on a row.
>>     317 del
>>     <       SQL_CURLH000C55
>>     317a317
>>     >       SQL_CURLH000C54
>>     Test Failed.
>>     *** End:   updatableResultSet jdk1.4.2_02 DerbyNetClient
>>     2005-05-26 23:13:22 ***
>>
>>     (Same error with 1.5 and 1.3)
>>
>>     I'm running with Linux 2.6.11. What I find strange, is that when I
>>     inspect the test failures in
>>     http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-178249.html
>>     <http://www.multinet.no/%7Esolberg/public/Apache/Derby/Limited/testSummary-178249.html>
>>     I see that the same test fails in the same way on all platforms,
>>     with the exception of the test run on a Linux 2.4.19 and jdk1.4.2_08
>>
>>     Comment anynone?
>>     --
>>     Bernt Marius Johnsen, Database Technology Group,
>>     Sun Microsystems, Trondheim, Norway
>>
>>

Re: DerbyNetClient/lang/updatableResultSet fails

Posted by Mamta Satoor <ms...@gmail.com>.
Hi,
 I am trying to understand the reasons behind updatableResultset test 
failure when using DerbyNetClient. Following is what I have found so far.
 Satheesh made a checkin on May 25th (revision 178519) to the master file 
DerbyNetClient/updatableResultSet.out which was as follows
+++ 
incubator/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/updatableResultSet.out
Wed May 25 12:39:51 2005
@@ -307,14 +307,14 @@
delete using first resultset
attempt to send deleteRow on the same row through a different resultset 
should throw an exception
SQL State : XCL08
-Got expected exception Cursor 'SQL_CURLH000C51' is not on a row.
+Got expected exception Cursor 'SQL_CURLH000C52' is not on a row.
Move to next row in the 2nd resultset and then delete using the second 
resultset
Positive Test11 - setting the fetch size to > 1 will be ignored by updatable 
resultset. Same as updatable cursors
Notice the Fetch Size in run time statistics output.
1
-----
Statement Name:
- SQL_CURLH000C54
+ SQL_CURLH000C55
Statement Text:
SELECT * FROM t1 FOR UPDATE of c1
Parse Time: 0

On May 26th, Bernt reported a diff which is reverse of master update done by 
Satheesh. Checkin from today (revision 179592) submitted by David seems to 
bring the master back to the state prior to Satheesh's checkin. 
 Also, Bernt, I looked at 
http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-178249.htmland
the reason you didn't see the failure on Linux
2.4.19 and jdk1.4.2_08 I think is because the test never got run on that 
machine for some reason. In the list of tests that ran as part of 
derbynetclientmats on Linux 2.4.19 and jdk1.4.2_08, I don't see 
updatableResultset test in there. Let me know if I have missed anything. But 
if I am right, then we don't need updatableResultSet_sed.properties since we 
should get same cursor name irrespective of different platforms. 
The only question I have is why did Satheesh need to change the master? I am 
running with classes and maybe there is something that shows up only with 
the jar files. Satheesh, please let me know if there is an environment that 
I have not tested which required the master update.
 thanks,
Mamta

On 5/26/05, Bernt M. Johnsen <Be...@sun.com> wrote: 

 When running derbyall, DerbyNetClient/lang/updatableResultSet fails
> the following way:
> 
> *** Start: updatableResultSet jdk1.4.2_02 DerbyNetClient 2005-05-26 
> 23:12:55 ***
> Initialize for framework: DerbyNetClient
> java -ms16777216 -mx33554432 -
> Dderby.system.home=/export/home/tmp/Derby/test/DerbyNetClient/updatableResultSet -
> Djava.security.manager -Djava.security.policy=/export/home/tmp/Derby/test/nwsvr.policy -
> Dcsinfo.codebase=/export/home/tmp/Derby/ trunk/jars/sane -
> Dcsinfo.serverhost=localhost -Dcsinfo.trustedhost=localhost org 
> .apache.derby.drda.NetworkServerControl start
> Attempt to shutdown framework: DerbyNetClient
> 310 del
> < Got expected exception Cursor 'SQL_CURLH000C52' is not on a row.
> 310a310
> > Got expected exception Cursor 'SQL_CURLH000C51' is not on a row.
> 317 del
> < SQL_CURLH000C55
> 317a317
> > SQL_CURLH000C54
> Test Failed.
> *** End: updatableResultSet jdk1.4.2_02 DerbyNetClient 2005-05-26 23:13:22 
> ***
> 
> (Same error with 1.5 and 1.3)
> 
> I'm running with Linux 2.6.11. What I find strange, is that when I
> inspect the test failures in
> 
> http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-178249.html
> I see that the same test fails in the same way on all platforms,
> with the exception of the test run on a Linux 2.4.19 and jdk1.4.2_08
> 
> Comment anynone?
> --
> Bernt Marius Johnsen, Database Technology Group,
> Sun Microsystems, Trondheim, Norway
>