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* <[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>> 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 >>> >>> > > >
