[jira] Closed: (DERBY-427) An error message when running in XA environment says cloudscape.LOG rather than derby.log
[ http://issues.apache.org/jira/browse/DERBY-427?page=all ] Mamta A. Satoor closed DERBY-427: - > An error message when running in XA environment says cloudscape.LOG rather > than derby.log > - > > Key: DERBY-427 > URL: http://issues.apache.org/jira/browse/DERBY-427 > Project: Derby > Type: Bug > Components: Unknown > Versions: 10.2.0.0 > Reporter: Mamta A. Satoor > Priority: Minor > Fix For: 10.2.0.0 > > While trying to connect in ij under XA environment, I get an error message > which talks about looking into cloudscape.LOG rather than derby.log Here are > the steps to reproduce > Just have derbytools.jar in the classpath and try to connect using ij as > follows > java -Dij.exceptionTrace=true org.apache.derby.tools.ij > xa_datasource 'c:/dellater/db1drda'; > The ij window throws following exception > IJ ERROR: org.apache.derby.impl.tools.ij.ijException: EmbeddedXADataSource > not in classpath, please put derby.jar file in your classpath : > EmbeddedXADataSource not in classpath, please put derby.jar file in your > classpath (see cloudcape.LOG) > The error message should say (see derby.log) rather than (see cloudscape.LOG) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Failure! - TinderBox_Derby 420200 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 420200/2006-07-08 23:32:57 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1675674 2 118.99% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-420200.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/420200.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/420200.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Commented: (DERBY-1208) Attempts to reuse a prepared statement after an execution-time error causes ASSERT failure in SANE mode, but work fine in INSANE.
[ http://issues.apache.org/jira/browse/DERBY-1208?page=comments#action_12419892 ] Kathey Marsden commented on DERBY-1208: --- Thanks Håvard for the patch and the test. It is especially good that we will now have coverage for failures during this part of execution. Your approach looks good to me. I ran the test and verified the original repro fails without your patch and passes with it. I wouldn't normally commit in this area but the patch looks pretty harmless, so if nobody objects, I will run derbyall and then commit Monday. It would be good if someone familiar with the SQL area also took a quick look. Kathey > Attempts to reuse a prepared statement after an execution-time error causes > ASSERT failure in SANE mode, but work fine in INSANE. > - > > Key: DERBY-1208 > URL: http://issues.apache.org/jira/browse/DERBY-1208 > Project: Derby > Type: Bug > Components: JDBC > Versions: 10.2.0.0 > Reporter: A B > Priority: Minor > Attachments: 1208.diff, d1208.java, derby.log > > Please see the comments in DERBY-1196 for the discussion that prompted the > filing of this issue. In short, if one attempts to reuse a prepared > statement with a new set of parameters after a previous call to execute that > statement has failed, the result will be an ASSERT failure in SANE mode. > When the same thing is done in INSANE mode, everything works as one might > expect it to. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1108) The test jdbcapi/setTransactionIsolation.java fails with ibm jvm1.5
[ http://issues.apache.org/jira/browse/DERBY-1108?page=all ] Kathey Marsden updated DERBY-1108: -- Derby Info: (was: [Patch Available]) Thanks Manjula for looking at this issue. I was not able to apply this patch in Eclipse. The message I got was not in patch format. Looking at the patch it seems that some lines are split like: --- java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/setTransact ionIsolation.java (revision 416106) Maybe that is the trouble. Perhaps a cut and paste of svn diff? In terms of content it looks like a lot of white space was added.It might be good just to revert add in the rs.next() with the comment and regenerate the patch with svn diff redirected to file. I'll uncheck patch available until a new patch is submitted. > The test jdbcapi/setTransactionIsolation.java fails with ibm jvm1.5 > --- > > Key: DERBY-1108 > URL: http://issues.apache.org/jira/browse/DERBY-1108 > Project: Derby > Type: Bug > Components: Regression Test Failure > Versions: 10.2.0.0 > Environment: java version "1.5.0" > Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20051104) > IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 > j9vmwi3223-2005110 > 3 (JIT enabled) > J9VM - 20051027_03723_lHdSMR > JIT - 20051027_1437_r8 > GC - 20051020_AA) > JCL - 20051102 > Reporter: Manjula Kutty > Assignee: Manjula Kutty > Attachments: svn_diff_06_21.txt, svn_stat_06_21.txt, test.java > > The test jdbcapi/setTransactionIsolation.java fails with ibmjvm15. I think > the cause of this failure is , the jvm is not throwing an exception while > trying to change the transaction isolation when there is holdable cursor on > a resultset. Other jvms like sun jdk1.5, ibm142 throws the expected > exception. while ibm15 does allow to change the transaction isolation when > there is a hold cursor on a result set. > Already reported this issue with the ibmjvm people and they are looking in to > it -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-100) Add support for insert functionality using JDBC 2.0 updatable resultset apis
[ http://issues.apache.org/jira/browse/DERBY-100?page=all ] Kathey Marsden updated DERBY-100: - Derby Info: [Release Note Needed] (was: [Patch Available, Release Note Needed]) Removing patch available. As best I can tell all patches for this issue have been committed. Please correct if I am wrong. > Add support for insert functionality using JDBC 2.0 updatable resultset apis > > > Key: DERBY-100 > URL: http://issues.apache.org/jira/browse/DERBY-100 > Project: Derby > Type: New Feature > Components: JDBC > Versions: 10.1.1.0 > Reporter: Mamta A. Satoor > Fix For: 10.2.0.0 > Attachments: DERBY-100-2.diff, DERBY-100-2.stat, DERBY-100-3.diff, > DERBY-100-3.stat, DERBY-100-4.diff, DERBY-100-4.stat, DERBY-100.diff, > DERBY-100.stat > > The JDBC 2.0 API introduced the ability to update/delete/insert rows from a > resultset using methods in the Java programming language rather than having > to send an SQL command. This Jira entry is to track the insert rows > functionality using JDBC 2.0 apis. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1491) Provide ALTER TABLE functionality to change a column's default value
[ http://issues.apache.org/jira/browse/DERBY-1491?page=all ] Bryan Pendleton reassigned DERBY-1491: -- Assign To: Bryan Pendleton > Provide ALTER TABLE functionality to change a column's default value > > > Key: DERBY-1491 > URL: http://issues.apache.org/jira/browse/DERBY-1491 > Project: Derby > Type: New Feature > Components: Documentation, SQL > Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.0.0, 10.1.2.1, 10.1.3.0, > 10.1.3.1 > Reporter: Bryan Pendleton > Assignee: Bryan Pendleton > > Provide a way to alter the default value for an existing column in an > existing table. The syntax should probably some variant of the ALTER TABLE > statement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1491) Provide ALTER TABLE functionality to change a column's default value
[ http://issues.apache.org/jira/browse/DERBY-1491?page=all ] Bryan Pendleton updated DERBY-1491: --- Attachment: modifyDefault_1.diff Attached is modifyDefault_1.diff, a patch proposal to support the statement ALTER TABLE tablename MODIFY COLUMN columnname DEFAULT defaultvalue; The keyword COLUMN is optional. There aren't very many tests in this patch yet; I intend to write more tests. > Provide ALTER TABLE functionality to change a column's default value > > > Key: DERBY-1491 > URL: http://issues.apache.org/jira/browse/DERBY-1491 > Project: Derby > Type: New Feature > Components: Documentation, SQL > Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.0.0, 10.1.2.1, 10.1.3.0, > 10.1.3.1 > Reporter: Bryan Pendleton > Assignee: Bryan Pendleton > Attachments: modifyDefault_1.diff > > Provide a way to alter the default value for an existing column in an > existing table. The syntax should probably some variant of the ALTER TABLE > statement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: How to add a new service to Derby?
Hi, I found out mostly by reading code and ofcourse, the comments inside the code. I played around with the code for a while to know how exactly Derby is working. I'll post my findings along with a code sample soon. I'll test it and post it on derby dev. Best Regards, Sanket On 7/7/06, Andreas Korneliussen <[EMAIL PROTECTED]> wrote: Hi, Sorry nobody answered your question. I am quite interested in this topic myself. Did you find the information in any Derby doc on the website, or did you find it by reading the code / javadoc ? Would you mind posting your findings to the derby-dev list ? Regards --Andreas Sanket Sharma wrote: > Okay...I've figured out the way. > > Thanks anyways, > > Regards, > Sanket > > On 7/6/06, Sanket Sharma <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I was tinkering with Derby code for some time with JMX in my mind. I >> was wondering if there is a "recommended way" of adding new services >> to derby? >> >> The code documentation in Monitor.java says describes following ways >> to boot services (please correct me if I'm wrong): >> >> 1) having a property in the application properties or the system (JVM) >> set. >> >> derby.service.service name=class name >> e.g. >> 2) Added to the properties automatically by the class >> org.apache.derby.jdbc.EmbeddedDriver e.g. >> derby.service.service name=class name >> >> Does this imply that If I have to add JMX as non persistan service, >> all I need to do is: >> 1)Create my java files and classes that implement the classes >> 2) Assuming my class name is SystemManager, >> java -Dderby.service.systemmanager = SystemManager? >> >> 3) Make sure SystemManager.class and related modules are in my classpath? >> >> or alternatively, add the same identifier and classname/factory name >> to application properties. >> >> Is that really all I need to do? I'm sure I'm missing something there. >> >> Regards, >> Sanket >>
[jira] Commented: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality
[ http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12419887 ] Mamta A. Satoor commented on DERBY-1330: derbyall suite finished with no new failures. > Provide runtime privilege checking for grant/revoke functionality > - > > Key: DERBY-1330 > URL: http://issues.apache.org/jira/browse/DERBY-1330 > Project: Derby > Type: Sub-task > Components: SQL > Versions: 10.2.0.0 > Reporter: Mamta A. Satoor > Assignee: Mamta A. Satoor > Attachments: AuthorizationModelForDerbySQLStandardAuthorization.html, > AuthorizationModelForDerbySQLStandardAuthorizationV2.html, > Derby1330PrivilegeCollectionV2diff.txt, > Derby1330PrivilegeCollectionV2stat.txt, > Derby1330PrivilegeCollectionV3diff.txt, > Derby1330PrivilegeCollectionV3stat.txt, > Derby1330ViewPrivilegeCollectionV1diff.txt, > Derby1330ViewPrivilegeCollectionV1stat.txt > > Additional work needs to be done for grant/revoke to make sure that only > users with required privileges can access various database objects. In order > to do that, first we need to collect the privilege requirements for various > database objects and store them in SYS.SYSREQUIREDPERM. Once we have this > information then when a user tries to access an object, the required > SYS.SYSREQUIREDPERM privileges for the object will be checked against the > user privileges in SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and > SYS.SYSROUTINEPERMS. The database object access will succeed only if the user > has the necessary privileges. > SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS are already > populated by Satheesh's work on DERBY-464. But SYS.SYSREQUIREDPERM doesn't > have any information in it at this point and hence no runtime privilege > checking is getting done at this point. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Revoke REFERENCES privilege and drop foreign key constraint
Hi, Based on functional specification attached to DERBY-1330, I am working on having REVOKE REFERENCES privilege drop all the foreign key constraints dependent on that privilege. I thought, this would involve going through SYSTABLEPERMS and SYSCOLPERMS in execute phase of of REVOKE statement to find all the privilege descriptors that would get impacted by the REVOKE REFERENCES statement. And then let the depenency manager find all the objects that depend on those privilege descriptors and send a REVOKE_PRIVILEGE to all those dependents. When the ConstraintDescriptor.makeInvalid method receives REOVKE_PRIVILEGE, it can simply call DataDictionary().dropConstraintDescriptor(...). But this doesn't seem to do the magic and does not clean up everything (for instance, after the REVOKE REFERENCE statement is over, TableDescriptor which had foreign key defined on it still holds on to the foreign key). I looked through alter table constant action to see what happens when a user issues a drop constraint foreignkeyname and it seems like there is lot more involved then simply calling the data dictionary to drop the constraint descriptor. In order to accomplish the same behavior, I am thinking that rather than calling just DataDictionary().dropConstraintDescriptor(...) method in the ConstraintDescriptor.makeInvalid method, I should issue a sql statement "drop constraint foreignkeyname" inside ConstraintDescriptor.makeInvalid method and let it take care of all the necessary steps. Does anyone have any thoughts on my approach? Thanks, Mamta
DERBY-1208 review
I do not see the email for my DERBY-1208 comment and review. Comment is here: http://issues.apache.org/jira/browse/DERBY-1208#action_12419892 Short story: I will commit this patch Monday but it would be really good to have someone familiar with the SQL area take a quick look. Additionally I will say I am sorry you had to wait three months for review. Kathey
[jira] Created: (DERBY-1492) Provide ALTER TABLE functionality to change a column from NULL to NOT NULL or vice versa
Provide ALTER TABLE functionality to change a column from NULL to NOT NULL or vice versa Key: DERBY-1492 URL: http://issues.apache.org/jira/browse/DERBY-1492 Project: Derby Type: New Feature Components: Documentation, SQL Versions: 10.1.3.1, 10.1.3.0, 10.1.2.1, 10.1.1.0, 10.0.2.1, 10.0.2.0, 10.2.0.0 Reporter: Bryan Pendleton Allow an existing column in an existing table to be changed from NULL to NOT NULL, or vice versa. Probably the syntax for this should be some variant on the ALTER TABLE statement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1404) i18nTest/iepnegativetests_ES and derbytools/iepnegativetests fails with ibm142 on linux
[ http://issues.apache.org/jira/browse/DERBY-1404?page=comments#action_12419868 ] Myrna van Lunteren commented on DERBY-1404: --- Please inform me of the jvm build number. I suspect a jvm issue as I've seen this test fail with one build of the ibm 142 jvm, yet pass with a subsequent build. Also please indicate the value of $LANG when you encountered this error. > i18nTest/iepnegativetests_ES and derbytools/iepnegativetests fails with > ibm142 on linux > > > Key: DERBY-1404 > URL: http://issues.apache.org/jira/browse/DERBY-1404 > Project: Derby > Type: Bug > Components: Regression Test Failure > Versions: 10.2.0.0 > Environment: -- Java Information -- > Java Version:1.4.2 > Java Vendor: IBM Corporation > Java home: /local1/cloudtst/dev/src/ibm142/jre > Java classpath: > /local1/cloudtst/dev/src/jars/insane/derby.jar:/local1/cloudtst > /dev/src/jars/insane/derbytools.jar:/local1/cloudtst/dev/src/jars/insane/derbyne > t.jar:/local1/cloudtst/dev/src/jars/insane/derbyclient.jar:/local1/cloudtst/dev/ > src/jars/insane/derbyTesting.jar:/local1/cloudtst/dev/src/jcc/db2jcc.jar:/local1 > /cloudtst/dev/src/jcc/db2jcc_license_c.jar:/local1/cloudtst/dev/src/jars/insane/ > derbyTesting.jar:/local1/cloudtst/dev/src/tools/java/jakarta-oro-2.0.8.jar:/loca > l1/cloudtst/dev/src/tools/java/junit.jar:/local1/cloudtst/dev/src/jars/insane/de > rbyLocale_de_DE.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_es.jar:/loc > al1/cloudtst/dev/src/jars/insane/derbyLocale_fr.jar:/local1/cloudtst/dev/src/jar > s/insane/derbyLocale_it.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_ja_ > JP.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_ko_KR.jar:/local1/cloudt > st/dev/src/jars/insane/derbyLocale_pt_BR.jar:/local1/cloudtst/dev/src/jars/insan > e/derbyLocale_zh_CN.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_zh_TW.j > ar:/local1/cloudtst/dev/src/jars/insane/derbyrun.jar: > OS name: Linux > OS architecture: x86 > OS version: 2.6.5-7.257-bigsmp > Java user name: cloudtst > Java user home: /u/cloudtst > Java user dir: > /local1/cloudtst/dev/src/NightlyBuildResults.2006-06-12/ibm142_ > derbyall > java.specification.name: Java Platform API Specification > java.specification.version: 1.4 > - Derby Information > JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 > [/local1/cloudtst/dev/src/jars/insane/derby.jar] 10.2.0.4 alpha - (413780) > [/local1/cloudtst/dev/src/jars/insane/derbytools.jar] 10.2.0.4 alpha - > (413780) > [/local1/cloudtst/dev/src/jars/insane/derbynet.jar] 10.2.0.4 alpha - (413780) > [/local1/cloudtst/dev/src/jars/insane/derbyclient.jar] 10.2.0.4 alpha - > (413780) > [/local1/cloudtst/dev/src/jcc/db2jcc.jar] 2.6 - (90) > [/local1/cloudtst/dev/src/jcc/db2jcc_license_c.jar] 2.6 - (90) > -- > - Locale Information - > Current Locale : [English/United States [en_US]] > Found support for locale: [de_DE] > version: 10.2.0.4 alpha - (413780) > Found support for locale: [es] > version: 10.2.0.4 alpha - (413780) > Found support for locale: [fr] > version: 10.2.0.4 alpha - (413780) > Found support for locale: [it] > version: 10.2.0.4 alpha - (413780) > Found support for locale: [ja_JP] > version: 10.2.0.4 alpha - (413780) > Found support for locale: [ko_KR] > version: 10.2.0.4 alpha - (413780) > Found support for locale: [pt_BR] > version: 10.2.0.4 alpha - (413780) > Found support for locale: [zh_CN] > version: 10.2.0.4 alpha - (413780) > Found support for locale: [zh_TW] > version: 10.2.0.4 alpha - (413780) > Reporter: Manjula Kutty > Assignee: Myrna van Lunteren > > * Diff file derbyall/i18nTest/iepnegativetests_ES.diff > *** Start: iepnegativetests_ES jdk1.4.2 derbyall:i18nTest 2006-06-12 22:29:12 > ** > * > 35 del > < ERROR XIE0I: Se ha producido una excepci EnC:>243< n de E/S al grabar datos > en > el archivo. > 35a35,37 > > ERROR 38000: Se he generado la excepci EnC:>243< n > > 'java.lang.ExceptionInIniti > alizerError' al evaluar una expresi EnC:>243< n. > > ERROR XJ001: Excepci EnC:>243< n de Java: ': > > java.lang.ExceptionInInitializerE > rror'. > > ERROR XJ001: Excepci EnC:>243< n de Java: 'access denied > > (java.lang.RuntimePer > mission charsetProvider): java.security.AccessControlException'. > 116 del > < ERROR XJ001: Excepci EnC:>243< n de Java: > 'java.io.UnsupportedEncodingExceptio > n: INCORRECTCODESET'. > 116a118 > > ERROR XJ001: Excepci EnC:>243< n de Java: 'java/nio/charset/Charset: > > java.lang > .NoClassDefFoundError'. > Test Failed. > *** End: iepnegativetests_ES jdk1.4.2 derbyall:i18nTest 2006-06-12 22:29:30 > ** -- This message is automatically genera
[jira] Assigned: (DERBY-1404) i18nTest/iepnegativetests_ES and derbytools/iepnegativetests fails with ibm142 on linux
[ http://issues.apache.org/jira/browse/DERBY-1404?page=all ] Myrna van Lunteren reassigned DERBY-1404: - Assign To: Myrna van Lunteren > i18nTest/iepnegativetests_ES and derbytools/iepnegativetests fails with > ibm142 on linux > > > Key: DERBY-1404 > URL: http://issues.apache.org/jira/browse/DERBY-1404 > Project: Derby > Type: Bug > Components: Regression Test Failure > Versions: 10.2.0.0 > Environment: -- Java Information -- > Java Version:1.4.2 > Java Vendor: IBM Corporation > Java home: /local1/cloudtst/dev/src/ibm142/jre > Java classpath: > /local1/cloudtst/dev/src/jars/insane/derby.jar:/local1/cloudtst > /dev/src/jars/insane/derbytools.jar:/local1/cloudtst/dev/src/jars/insane/derbyne > t.jar:/local1/cloudtst/dev/src/jars/insane/derbyclient.jar:/local1/cloudtst/dev/ > src/jars/insane/derbyTesting.jar:/local1/cloudtst/dev/src/jcc/db2jcc.jar:/local1 > /cloudtst/dev/src/jcc/db2jcc_license_c.jar:/local1/cloudtst/dev/src/jars/insane/ > derbyTesting.jar:/local1/cloudtst/dev/src/tools/java/jakarta-oro-2.0.8.jar:/loca > l1/cloudtst/dev/src/tools/java/junit.jar:/local1/cloudtst/dev/src/jars/insane/de > rbyLocale_de_DE.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_es.jar:/loc > al1/cloudtst/dev/src/jars/insane/derbyLocale_fr.jar:/local1/cloudtst/dev/src/jar > s/insane/derbyLocale_it.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_ja_ > JP.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_ko_KR.jar:/local1/cloudt > st/dev/src/jars/insane/derbyLocale_pt_BR.jar:/local1/cloudtst/dev/src/jars/insan > e/derbyLocale_zh_CN.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_zh_TW.j > ar:/local1/cloudtst/dev/src/jars/insane/derbyrun.jar: > OS name: Linux > OS architecture: x86 > OS version: 2.6.5-7.257-bigsmp > Java user name: cloudtst > Java user home: /u/cloudtst > Java user dir: > /local1/cloudtst/dev/src/NightlyBuildResults.2006-06-12/ibm142_ > derbyall > java.specification.name: Java Platform API Specification > java.specification.version: 1.4 > - Derby Information > JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 > [/local1/cloudtst/dev/src/jars/insane/derby.jar] 10.2.0.4 alpha - (413780) > [/local1/cloudtst/dev/src/jars/insane/derbytools.jar] 10.2.0.4 alpha - > (413780) > [/local1/cloudtst/dev/src/jars/insane/derbynet.jar] 10.2.0.4 alpha - (413780) > [/local1/cloudtst/dev/src/jars/insane/derbyclient.jar] 10.2.0.4 alpha - > (413780) > [/local1/cloudtst/dev/src/jcc/db2jcc.jar] 2.6 - (90) > [/local1/cloudtst/dev/src/jcc/db2jcc_license_c.jar] 2.6 - (90) > -- > - Locale Information - > Current Locale : [English/United States [en_US]] > Found support for locale: [de_DE] > version: 10.2.0.4 alpha - (413780) > Found support for locale: [es] > version: 10.2.0.4 alpha - (413780) > Found support for locale: [fr] > version: 10.2.0.4 alpha - (413780) > Found support for locale: [it] > version: 10.2.0.4 alpha - (413780) > Found support for locale: [ja_JP] > version: 10.2.0.4 alpha - (413780) > Found support for locale: [ko_KR] > version: 10.2.0.4 alpha - (413780) > Found support for locale: [pt_BR] > version: 10.2.0.4 alpha - (413780) > Found support for locale: [zh_CN] > version: 10.2.0.4 alpha - (413780) > Found support for locale: [zh_TW] > version: 10.2.0.4 alpha - (413780) > Reporter: Manjula Kutty > Assignee: Myrna van Lunteren > > * Diff file derbyall/i18nTest/iepnegativetests_ES.diff > *** Start: iepnegativetests_ES jdk1.4.2 derbyall:i18nTest 2006-06-12 22:29:12 > ** > * > 35 del > < ERROR XIE0I: Se ha producido una excepci EnC:>243< n de E/S al grabar datos > en > el archivo. > 35a35,37 > > ERROR 38000: Se he generado la excepci EnC:>243< n > > 'java.lang.ExceptionInIniti > alizerError' al evaluar una expresi EnC:>243< n. > > ERROR XJ001: Excepci EnC:>243< n de Java: ': > > java.lang.ExceptionInInitializerE > rror'. > > ERROR XJ001: Excepci EnC:>243< n de Java: 'access denied > > (java.lang.RuntimePer > mission charsetProvider): java.security.AccessControlException'. > 116 del > < ERROR XJ001: Excepci EnC:>243< n de Java: > 'java.io.UnsupportedEncodingExceptio > n: INCORRECTCODESET'. > 116a118 > > ERROR XJ001: Excepci EnC:>243< n de Java: 'java/nio/charset/Charset: > > java.lang > .NoClassDefFoundError'. > Test Failed. > *** End: iepnegativetests_ES jdk1.4.2 derbyall:i18nTest 2006-06-12 22:29:30 > ** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1491) Provide ALTER TABLE functionality to change a column's default value
Provide ALTER TABLE functionality to change a column's default value Key: DERBY-1491 URL: http://issues.apache.org/jira/browse/DERBY-1491 Project: Derby Type: New Feature Components: Documentation, SQL Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.0.0, 10.1.2.1, 10.1.3.0, 10.1.3.1 Reporter: Bryan Pendleton Provide a way to alter the default value for an existing column in an existing table. The syntax should probably some variant of the ALTER TABLE statement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1490) Provide ALTER TABLE RENAME COLUMN functionality
Provide ALTER TABLE RENAME COLUMN functionality --- Key: DERBY-1490 URL: http://issues.apache.org/jira/browse/DERBY-1490 Project: Derby Type: New Feature Components: Documentation, SQL Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.0.0, 10.1.2.1, 10.1.3.0, 10.1.3.1 Reporter: Bryan Pendleton Provide a way to rename a column in an existing table. Possible syntax could be: ALTER TABLE tablename RENAME COLUMN oldcolumn TO newcolumn; Feature should properly handle the possibility that the column is currently used in constraints, views, indexes, triggers, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1489) Provide ALTER TABLE DROP COLUMN functionality
[ http://issues.apache.org/jira/browse/DERBY-1489?page=all ] Bryan Pendleton updated DERBY-1489: --- Attachment: dropColumn_2.diff Attachment dropColumn_2.diff continues the work done in DERBY-396's dropColumn_1.diff by adding a number of additional tests, and by modifying the db2Compatibility test. With this diff, derbyall passes cleanly. Feedback about the compiler changes in this diff would be wonderful, as would feedback about additional test cases to add. > Provide ALTER TABLE DROP COLUMN functionality > - > > Key: DERBY-1489 > URL: http://issues.apache.org/jira/browse/DERBY-1489 > Project: Derby > Type: New Feature > Components: Documentation, SQL > Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.0.0, 10.1.2.1, 10.1.3.0, > 10.1.3.1 > Reporter: Bryan Pendleton > Assignee: Bryan Pendleton > Fix For: 10.2.0.0 > Attachments: dropColumn_2.diff > > Provide a way to drop a column from an existing table. Possible syntax would > be: > ALTER TABLE tablename DROP COLUMN columnname CASCADE / RESTRICT; > Feature should properly handle columns which are used in constraints, views, > triggers, indexes, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1489) Provide ALTER TABLE DROP COLUMN functionality
Provide ALTER TABLE DROP COLUMN functionality - Key: DERBY-1489 URL: http://issues.apache.org/jira/browse/DERBY-1489 Project: Derby Type: New Feature Components: Documentation, SQL Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.0.0, 10.1.2.1, 10.1.3.0, 10.1.3.1 Reporter: Bryan Pendleton Assigned to: Bryan Pendleton Fix For: 10.2.0.0 Provide a way to drop a column from an existing table. Possible syntax would be: ALTER TABLE tablename DROP COLUMN columnname CASCADE / RESTRICT; Feature should properly handle columns which are used in constraints, views, triggers, indexes, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-396) Support for ALTER STATEMENT to DROP , MODIFY, RENAME a COLUMN
[ http://issues.apache.org/jira/browse/DERBY-396?page=comments#action_12419866 ] Bryan Pendleton commented on DERBY-396: --- I propose to file separate JIRA issues for the topics described here: 1) drop column 2) rename column 3) change column from null to not null, or vice versa 4) change column default value 5) change column datatype DERBY-119 already exists to track issue (3); I will be filing 4 new issues, linked to this one, to track the other topics. DERBY-168 was previously filed for issue (4), but was closed by changing the documentation, so I will open a new issue to track addition of the functionality. > Support for ALTER STATEMENT to DROP , MODIFY, RENAME a COLUMN > -- > > Key: DERBY-396 > URL: http://issues.apache.org/jira/browse/DERBY-396 > Project: Derby > Type: New Feature > Components: SQL > Environment: LINUX > Reporter: Kumar Matcha > Assignee: Bryan Pendleton > Attachments: dropColumn_1.diff > > Alter Statement should support dropping a column, modifying a column to a > different data type , rename a column. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-982) sysinfo api does not provide genus name for client
[ http://issues.apache.org/jira/browse/DERBY-982?page=comments#action_12419860 ] Kathey Marsden commented on DERBY-982: -- Sorry andrew I never got back to this patch after you added the tests. The tests look fine to me too. Thanks for the fix. > sysinfo api does not provide genus name for client > -- > > Key: DERBY-982 > URL: http://issues.apache.org/jira/browse/DERBY-982 > Project: Derby > Type: Bug > Components: Tools > Versions: 10.1.2.1 > Reporter: Kathey Marsden > Assignee: Andrew McIntyre > Fix For: 10.2.0.0 > Attachments: derby-982.diff, derby-982_v2.diff > > The sysinfo api does not provide access to the genus name for client to allow > applications to retrieve information from sysinfo about the client > information. > http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/tools/sysinfo.html > Note: Currently ProductGenusNames has a genus name for network server but > network server is closely tied to the engine so should always have the same > version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Writing language tests using JUnit.
b) I take it DerbyJUnitTest is deprecated. This class does have some useful methods like assertRow/assertScalar etc which I will need. Is it OK to copy these methods and/or add similar utility methods in BaseJDBCTestCase? Yes, you should feel free to add any utility methods to BaseJDBCTestCase that you find useful, and feel free to copy any methods from DerbyJUnitTest over that you need. Note that there are two Base classes, BaseTestCase and BaseJDBCTestCase. I'm not sure I'm entirely clear on the split, it might be best to review the discussion on the list surrounding their creation and separation. I think generic configuration and utility methods go into BaseTestCase and utility methods for exercising JDBC methods go into BaseJDBCTestCase. So something like assertRow() in DerbyJUnitTest would probably go into BaseJDBCTestCase, whereas something like println() or alarm() would go into BaseTestCase. Agree. One of the reasons we chose to split BaseTestCase and BaseJDBCTestCase is that BaseTestCase could be used to write tests which do not use the JDBC interface (i.e to write store tests or other types of unit tests), and there is no need for the jdbc helper methods in those subclasses. When moving methods into BaseJDBCTestCase be careful of not including stuff that may break all junit tests from running in the j9/j2me framework. We have previously seen tests failing to load in the j9/j2me framework because some methods had signatures with classes which are not available in that framework (like XADataSource ?). --Andreas
[jira] Commented: (DERBY-1486) ERROR 40XD0 - When exracting Blob from a database
[
http://issues.apache.org/jira/browse/DERBY-1486?page=comments#action_12419859 ]
David Heath commented on DERBY-1486:
I just have added close() and flush() to the objStream, re-ran the code and it
does not make a difference - I think the reason it works without them is
because the streams are memory and not file based. Thus that is not the
problem.
> ERROR 40XD0 - When exracting Blob from a database
> --
>
> Key: DERBY-1486
> URL: http://issues.apache.org/jira/browse/DERBY-1486
> Project: Derby
> Type: Bug
> Components: Unknown
> Versions: 10.1.2.1
> Environment: Windows XP
> Reporter: David Heath
>
> An exception occurs when extracting a Blob from a database.
> The following code, will ALWAYS fail with the Exception:
> java.io.IOException: ERROR 40XD0: Container has been closed
> at
> org.apache.derby.impl.store.raw.data.OverflowInputStream.fillByteHolder(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.BufferedByteHolderInputStream.read(Unknown
> Source)
> at java.io.DataInputStream.read(Unknown Source)
> at java.io.FilterInputStream.read(Unknown Source)
> at java.io.ObjectInputStream$PeekInputStream.read(Unknown Source)
> at java.io.ObjectInputStream$PeekInputStream.readFully(Unknown Source)
> at java.io.ObjectInputStream$BlockDataInputStream.readDoubles(Unknown
> Source)
> at java.io.ObjectInputStream.readArray(Unknown Source)
> at java.io.ObjectInputStream.readObject0(Unknown Source)
> at java.io.ObjectInputStream.readObject(Unknown Source)
> at BlobTest.readRows(BlobTest.java:81)
> at BlobTest.main(BlobTest.java:23)
> CODE:
> import java.io.*;
> import java.sql.*;
> import java.util.*;
> public class BlobTest
> {
> private static final String TABLE1 = "CREATE TABLE TABLE_1 ( "
> + "ID INTEGER NOT NULL, "
> + "COL_2 INTEGER NOT NULL, "
> + "PRIMARY KEY (ID) )";
> private static final String TABLE2 = "CREATE TABLE TABLE_2 ( "
> + "ID INTEGER NOT NULL, "
> + "COL_BLOB BLOB, "
> + "PRIMARY KEY (ID) )";
> public static void main(String... args) {
> try {
> createDBandTables();
> Connection con = getConnection();
> addRows(con, 1, 1);
> readRows(con, 1);
> con.close();
> }
> catch(Exception exp) {
> exp.printStackTrace();
> }
> }
> private static void addRows(Connection con, int size, int id)
> throws Exception
> {
> String sql = "INSERT INTO TABLE_1 VALUES(?, ?)";
> PreparedStatement pstmt = con.prepareStatement(sql);
> pstmt.setInt(1, id);
> pstmt.setInt(2, 2);
> pstmt.executeUpdate();
> pstmt.close();
> double[] array = new double[size];
> array[size-1] = 1.23;
> sql = "INSERT INTO TABLE_2 VALUES(?, ?)";
> pstmt = con.prepareStatement(sql);
> pstmt.setInt(1, id);
> ByteArrayOutputStream byteStream = new ByteArrayOutputStream();
> ObjectOutputStream objStream = new ObjectOutputStream(byteStream);
> objStream.writeObject(array); // Convert object to byte stream
> byte[] bytes = byteStream.toByteArray();
> ByteArrayInputStream inStream = new ByteArrayInputStream(bytes);
> pstmt.setBinaryStream(2, inStream, bytes.length);
> pstmt.executeUpdate();
> pstmt.close();
> }
> private static void readRows(Connection con, int id) throws Exception
> {
> String sql = "SELECT * FROM TABLE_2";
> Statement stmt = con.createStatement();
> ResultSet rs = stmt.executeQuery(sql);
> if (rs.next()) {
> rs.getInt(1);
> readTable1(con, id);
> InputStream stream = rs.getBinaryStream(2);
> ObjectInputStream objStream = new ObjectInputStream(stream);
> Object obj = objStream.readObject(); // FAILS HERE
> double[] array = (double[]) obj;
> System.out.println(array.length);
> }
> rs.close();
> stmt.close();
> }
> private static void readTable1(Connection con, int id) throws Exception {
> String sql = "SELECT ID FROM TABLE_1 WHERE ID=" + id;
> Statement stmt = con.createStatement();
> ResultSet rs = stmt.executeQuery(sql);
> if (rs.next()) {
> }
> rs.close();
> stmt.close();
> }
>
> private static Connection getConnection() throws Exception {
> String driver="org.apache.derby.jdbc.EmbeddedDriver";
> Properties p = System.getProperties();
> p.put("derby.system.home", "C:\\databases\\sample");
>
> Class.forName(driver);
> String url = "jdbc:derby:derbyBlob";
> Connection con = DriverManager.getConnection(url);
[jira] Updated: (DERBY-1488) Provide an Eclipse feature for the org.apache.derby.core plug-in
[ http://issues.apache.org/jira/browse/DERBY-1488?page=all ] Ian Leslie updated DERBY-1488: -- Attachment: DerbyAboutBox.PNG This is what the Derby about information looks like for an Eclipse RCP application as displayed from the link in its main about box. > Provide an Eclipse feature for the org.apache.derby.core plug-in > > > Key: DERBY-1488 > URL: http://issues.apache.org/jira/browse/DERBY-1488 > Project: Derby > Type: Improvement > Components: Eclipse Plug-in > Reporter: Ian Leslie > Priority: Minor > Attachments: DerbyAboutBox.PNG, DerbyInAboutBox.PNG, > derby_core_plugin_feature_10.1.3.zip > > I recently upgraded to 10.1.3.1 and was pleased to see an eclipse plug-in > available. Previously I had been rolling my own out of the regular install. > I am using Derby in an RCP application and therefore have a desire to have a > feature too. In order for the Derby information to appear with the Derby > Logo at the top level of an RCP application's about box there needs to be a > feature as well as a plug-in. I suggest that a feature be created for the > .core plug-in and that the .core plug-in have Eclipse branding information > added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1488) Provide an Eclipse feature for the org.apache.derby.core plug-in
[ http://issues.apache.org/jira/browse/DERBY-1488?page=all ] Ian Leslie updated DERBY-1488: -- Attachment: DerbyInAboutBox.PNG This is what the Derby feature contribution looks like in an Eclipse RCP application. When the customer clicks on the Derby icon the see the Derby about box. > Provide an Eclipse feature for the org.apache.derby.core plug-in > > > Key: DERBY-1488 > URL: http://issues.apache.org/jira/browse/DERBY-1488 > Project: Derby > Type: Improvement > Components: Eclipse Plug-in > Reporter: Ian Leslie > Priority: Minor > Attachments: DerbyInAboutBox.PNG, derby_core_plugin_feature_10.1.3.zip > > I recently upgraded to 10.1.3.1 and was pleased to see an eclipse plug-in > available. Previously I had been rolling my own out of the regular install. > I am using Derby in an RCP application and therefore have a desire to have a > feature too. In order for the Derby information to appear with the Derby > Logo at the top level of an RCP application's about box there needs to be a > feature as well as a plug-in. I suggest that a feature be created for the > .core plug-in and that the .core plug-in have Eclipse branding information > added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1488) Provide an Eclipse feature for the org.apache.derby.core plug-in
[ http://issues.apache.org/jira/browse/DERBY-1488?page=all ] Ian Leslie updated DERBY-1488: -- Attachment: derby_core_plugin_feature_10.1.3.zip I have attached a .zip file that represents the modified contents of derby_core_plugin_10.1.3.zip to include a feature as well as branding information to the plug-in to support about boxes in Eclipse RCP applications. > Provide an Eclipse feature for the org.apache.derby.core plug-in > > > Key: DERBY-1488 > URL: http://issues.apache.org/jira/browse/DERBY-1488 > Project: Derby > Type: Improvement > Components: Eclipse Plug-in > Reporter: Ian Leslie > Priority: Minor > Attachments: derby_core_plugin_feature_10.1.3.zip > > I recently upgraded to 10.1.3.1 and was pleased to see an eclipse plug-in > available. Previously I had been rolling my own out of the regular install. > I am using Derby in an RCP application and therefore have a desire to have a > feature too. In order for the Derby information to appear with the Derby > Logo at the top level of an RCP application's about box there needs to be a > feature as well as a plug-in. I suggest that a feature be created for the > .core plug-in and that the .core plug-in have Eclipse branding information > added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1488) Provide an Eclipse feature for the org.apache.derby.core plug-in
Provide an Eclipse feature for the org.apache.derby.core plug-in Key: DERBY-1488 URL: http://issues.apache.org/jira/browse/DERBY-1488 Project: Derby Type: Improvement Components: Eclipse Plug-in Reporter: Ian Leslie Priority: Minor I recently upgraded to 10.1.3.1 and was pleased to see an eclipse plug-in available. Previously I had been rolling my own out of the regular install. I am using Derby in an RCP application and therefore have a desire to have a feature too. In order for the Derby information to appear with the Derby Logo at the top level of an RCP application's about box there needs to be a feature as well as a plug-in. I suggest that a feature be created for the .core plug-in and that the .core plug-in have Eclipse branding information added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality
[ http://issues.apache.org/jira/browse/DERBY-1330?page=all ] Mamta A. Satoor updated DERBY-1330: --- Attachment: Derby1330PrivilegeCollectionV3diff.txt Derby1330PrivilegeCollectionV3stat.txt Dan, truly appreciate your time on the patch review. I think I have taken care of all your comments in the attached review package ( Derby1330PrivilegeCollectionV3diff.txt) Along with javadoc comments, method and variable renaming, I have abstracted the actual dependency saving code from CreateViewConstantAction, CreateConstraintConstantAction and CreateTriggerConstantAction into DDLConstantAction as 2 methods. Running the derbyall suite suite right noww for sanity check. Please let me know if I missed any of your feedback or if you/anyone else has any comments on the latest review package. svn stat -q output attached as Derby1330PrivilegeCollectionV3stat.txt > Provide runtime privilege checking for grant/revoke functionality > - > > Key: DERBY-1330 > URL: http://issues.apache.org/jira/browse/DERBY-1330 > Project: Derby > Type: Sub-task > Components: SQL > Versions: 10.2.0.0 > Reporter: Mamta A. Satoor > Assignee: Mamta A. Satoor > Attachments: AuthorizationModelForDerbySQLStandardAuthorization.html, > AuthorizationModelForDerbySQLStandardAuthorizationV2.html, > Derby1330PrivilegeCollectionV2diff.txt, > Derby1330PrivilegeCollectionV2stat.txt, > Derby1330PrivilegeCollectionV3diff.txt, > Derby1330PrivilegeCollectionV3stat.txt, > Derby1330ViewPrivilegeCollectionV1diff.txt, > Derby1330ViewPrivilegeCollectionV1stat.txt > > Additional work needs to be done for grant/revoke to make sure that only > users with required privileges can access various database objects. In order > to do that, first we need to collect the privilege requirements for various > database objects and store them in SYS.SYSREQUIREDPERM. Once we have this > information then when a user tries to access an object, the required > SYS.SYSREQUIREDPERM privileges for the object will be checked against the > user privileges in SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and > SYS.SYSROUTINEPERMS. The database object access will succeed only if the user > has the necessary privileges. > SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS are already > populated by Satheesh's work on DERBY-464. But SYS.SYSREQUIREDPERM doesn't > have any information in it at this point and hence no runtime privilege > checking is getting done at this point. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Failure! - Derby 419932 - Sun DBTG
[Auto-generated mail] *Derby* 419932/2006-07-07 19:46:12 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 2715713 0 102.54% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-419932.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/419932.html *Jvm: 1.5* NA NA NANA CYGWIN_NT-5.1_i686-unknown 2675673 2 115.40% CYGWIN_NT-5.2_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 0675675 2 105.74% Linux-2.6.9-34.ELsmp_x86_64-x86_64 3675672 2 176.25% SunOS-5.10_i86pc-i386 0675675 2 138.86% SunOS-5.10_sun4u-sparc NA NA NANA SunOS-5.11_i86pc-i386 0675675 2 112.55% SunOS-5.9_sun4u-sparc Details in http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-419932.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/419932.html *Jvm: 1.4* NA NA NANA CYGWIN_NT-5.1_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 0669669 4 106.24% Linux-2.6.9-34.ELsmp_x86_64-x86_64 3669666 4 209.57% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-419932.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/419932.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/419932.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
