[jira] Commented: (DERBY-2518) convert lang/releaseCompileLocks.sql to junit
[
https://issues.apache.org/jira/browse/DERBY-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513461
]
Knut Anders Hatlen commented on DERBY-2518:
---
> hm...How do I throw the SQLException from the static initializer?
catch (SQLException se) {
throw new ExceptionInInitializerError(se);
}
> convert lang/releaseCompileLocks.sql to junit
> --
>
> Key: DERBY-2518
> URL: https://issues.apache.org/jira/browse/DERBY-2518
> Project: Derby
> Issue Type: Test
> Components: Test
>Reporter: Ramandeep Kaur
>Assignee: Ramandeep Kaur
>Priority: Minor
> Fix For: 10.4.0.0
>
> Attachments: DERBY-2518_071707.diff, DERBY_2518.diff, DERBY_2518.stat
>
>
> convert lang/releaseCompileLocks.sql to junit
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2878) Scan protection handle could be cached in BasePage
[ https://issues.apache.org/jira/browse/DERBY-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-2878: -- Attachment: derby-2878-3a.diff Attaching a new and simpler patch (3a) which replaces patch 3. The new patch only makes these changes: 1) replaces the field current_scan_pageno (a long) in BTreeRowPosition with current_scan_protectionHandle (a RecordHandle which is cached in BasePage) 2) changes the signature of BTreeLockingPolicy.unlockScan() to take a RecordHandle 3) removes unused method OpenBTree.makeRecordHandle() With this patch, a B-tree scan does not allocate any protection record handle if the leaf pages it visits are in the page cache and have been scanned before. Derbyall and suites.All passed with the new patch. > Scan protection handle could be cached in BasePage > -- > > Key: DERBY-2878 > URL: https://issues.apache.org/jira/browse/DERBY-2878 > Project: Derby > Issue Type: Improvement > Components: Performance, Store >Affects Versions: 10.4.0.0 >Reporter: Knut Anders Hatlen >Assignee: Knut Anders Hatlen >Priority: Minor > Attachments: derby-2878-1.diff, derby-2878-1.stat, > derby-2878-1b.diff, derby-2878-2.diff, derby-2878-3.diff, derby-2878-3.stat, > derby-2878-3a.diff > > > Each time a leaf node in a B-tree is visited in an index scan, a scan > protection row is locked and unlocked. Both the lock operation and the unlock > operation will allocate a new RecordId object representing the scan > protection row (the unlock operation additionally allocates a PageKey object > for the RecordId). Since the scan protection handle created will be identical > (seen from equals()) each time it is created for a page, it would make sense > to cache it in BasePage. Then we only need to allocate the protection handle > for a page once for as long as it stays in the page cache. This would save > three object allocations per single-record lookup via index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2940) CollationTest fail after hard upgrade from 10.2
[ https://issues.apache.org/jira/browse/DERBY-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513501 ] Øystein Grøvlen commented on DERBY-2940: Can anyone who knows the collation work tell whether this is expected behavior or not? If this is expected behavior, please, feel free to close this issue. > CollationTest fail after hard upgrade from 10.2 > --- > > Key: DERBY-2940 > URL: https://issues.apache.org/jira/browse/DERBY-2940 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.3.1.2 > Environment: Hard upgrade of 10.2 database. >Reporter: Øystein Grøvlen > > I create a database with 10.2.2.0 and then do a hard upgrade to 10.3.1.2: > > java -jar db-derby-10.2.2.0-lib/lib/derbyrun.jar ij > ij version 10.2 > ij> connect 'jdbc:derby:system/wombat;create=true'; > ij> exit; > > java -jar db-derby-10.3.1.2-bin/lib/derbyrun.jar ij > ij version 10.3 > ij> connect 'jdbc:derby:system/wombat;upgrade=true'; > ij> exit; > If I then run the CollationTest, I get: > There was 1 failure: > 1) > testDefaultCollation(org.apache.derbyTesting.functionTests.tests.lang.CollationTest)junit.framework.AssertionFailedError: > Column value mismatch @ column '1', row 1: > Expected: >UCS_BASIC< > Found:>null< > at > org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:873) > at > org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:766) > at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:704) > at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:662) > at > org.apache.derbyTesting.functionTests.tests.lang.CollationTest.checkLangBasedQuery(CollationTest.java:1014) > at > org.apache.derbyTesting.functionTests.tests.lang.CollationTest.testDefaultCollation(CollationTest.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.extensions.TestSetup.run(TestSetup.java:25) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > FAILURES!!! > Tests run: 4, Failures: 1, Errors: 0 > If I create the database with 10.3 before running the test, the tests suceeds. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2936) Use java.nio.ByteBuffer for buffering in DDMWriter
[ https://issues.apache.org/jira/browse/DERBY-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-2936: -- Attachment: derby-2936-2.stat derby-2936-2.diff Attaching a patch which removes the use of String.getBytes(String) in DDMWriter. It does the following: 1) Removes an unused constructor and an unused writeString() method so that they don't have to be updated with duplicated and unused code. 2) Adds a CharsetEncoder object for the default encoding to the DDMWriters. (I made the encoder replace unmappable characters with the default replacement character. It is undefined what String.getBytes(String) does with such characters, so this might or might not match the old behaviour depending on the JVM, but the new implementation will at least have a clearly defined behaviour across different JVMs.) 3) Changes writeString() and writeLDString() so that they encode the strings directly into the output buffer (using the CharsetEncoder object) instead of encoding it into a new temporary byte array before copying it to the output buffer. 4) Removes constants and helper methods used for truncating the byte sequence on a character boundary in writeLDString() since CharsetEncoder automatically truncates it correctly. Derbyall and suites.All ran cleanly. > Use java.nio.ByteBuffer for buffering in DDMWriter > -- > > Key: DERBY-2936 > URL: https://issues.apache.org/jira/browse/DERBY-2936 > Project: Derby > Issue Type: Improvement > Components: Network Server >Reporter: Knut Anders Hatlen >Assignee: Knut Anders Hatlen >Priority: Minor > Attachments: d2936-1.diff, derby-2936-2.diff, derby-2936-2.stat > > > org.apache.derby.impl.drda.DDMWriter uses a byte array as a buffer. Wrapping > the array in a java.nio.ByteBuffer has some advantages, for instance: > - utility methods for encoding primitive types into the byte array could be > used instead of manually encoding the values > - it allows us to encode strings directly into the buffer (using a > CharsetEncoder) without doing an expensive String.getBytes(String encoding) > in an intermediate step > By using a utility class, the code becomes easier to maintain. Also, > ByteBuffer allows us to access the backing byte array without going through > the ByteBuffer interface, so we still have the possibility to modify the byte > array directly in cases where that's more convenient. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2936) Use java.nio.ByteBuffer for buffering in DDMWriter
[ https://issues.apache.org/jira/browse/DERBY-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-2936: -- Derby Info: [Patch Available] > Use java.nio.ByteBuffer for buffering in DDMWriter > -- > > Key: DERBY-2936 > URL: https://issues.apache.org/jira/browse/DERBY-2936 > Project: Derby > Issue Type: Improvement > Components: Network Server >Reporter: Knut Anders Hatlen >Assignee: Knut Anders Hatlen >Priority: Minor > Attachments: d2936-1.diff, derby-2936-2.diff, derby-2936-2.stat > > > org.apache.derby.impl.drda.DDMWriter uses a byte array as a buffer. Wrapping > the array in a java.nio.ByteBuffer has some advantages, for instance: > - utility methods for encoding primitive types into the byte array could be > used instead of manually encoding the values > - it allows us to encode strings directly into the buffer (using a > CharsetEncoder) without doing an expensive String.getBytes(String encoding) > in an intermediate step > By using a utility class, the code becomes easier to maintain. Also, > ByteBuffer allows us to access the backing byte array without going through > the ByteBuffer interface, so we still have the possibility to modify the byte > array directly in cases where that's more convenient. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: PROPOSAL: 10.3.2.x release in mid-September?
Stanley Bradbury wrote: As stated in my comment on the TERRITORY_BASED collation problem at: https://issues.apache.org/jira/browse/DERBY-2896#action_12513395 This problem greatly limits the use of TERRITORY_BASED collation and for the sake of that feature needs to be fixed quickly. Rather than hold up the release along with all the other features and fixes I am proposing a 10.3.2.x release be planned for 4-6 weeks following 10.3.2.1 (assuming this is approved next week). This release would correct DERBY-2896 and any other problems that might be reported and backported in the early days of 10.3. Does this sound like a good plan or would producing a 'fix' release be a lot more work/testing than stopping 10.3.1.2 and waiting for this to be fixed? I figure it best to hash this out now rather than waiting until the day of the vote. I think a 10.3.2 release that includes a number of bugfixes that do not make it for 10.3.1 would be a good thing. The motivation in the community to spend time on fixing these bugs will decide how useful it is, I guess. If a significant number of bugs are fixed, then the work involved in creating a 10.3.2 release will seem worth it. In principle I think the 10.3.1 release should be judged independently of whether there will be a bugfix release shortly after or not. I don't think a future bugfix release should influence whether a bug is a blocker or not for this release. Vemund
[jira] Commented: (DERBY-1387) Add JMX extensions to Derby
[ https://issues.apache.org/jira/browse/DERBY-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513532 ] Ole Gunnar Borstad commented on DERBY-1387: --- I want to read and write database-wide properties dynamically. Tuning Derby document says to use the system procedures through SQL statements. Does this mean I need to setup a connection? Is there any reason not to have a connection in a management service, i.e exposing Derby of additional overhead etc.? > Add JMX extensions to Derby > --- > > Key: DERBY-1387 > URL: https://issues.apache.org/jira/browse/DERBY-1387 > Project: Derby > Issue Type: New Feature > Components: Services >Reporter: Sanket Sharma >Assignee: Ole Gunnar Borstad > Attachments: derbyjmx.patch, jmx.diff, jmx.stat, Requirements for JMX > Updated.html, Requirements for JMX.html, Requirements for JMX.zip > > > This is a draft requirement specification for adding monitoring and > management extensions to Apache Derby using JMX. The requirements document > has been uploaded on JIRA as well as the Derby Wiki page at > http://wiki.apache.org/db-derby/_Requirement_Specifications_for_Monitoring_%26_Management_Extensions_using_JMX > Developers and Users are requested to please look at the document (feature > list in particular) and add their own rating to features by adding a coloumn > to the table. > Comments are welcome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2947) Reoccurrence of DERBY-861: Intermittent failure of store/readlocks.sql
Reoccurrence of DERBY-861: Intermittent failure of store/readlocks.sql --- Key: DERBY-2947 URL: https://issues.apache.org/jira/browse/DERBY-2947 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.3.1.2 Environment: derbyall fail * derbyall/storeall/storeall.fail:store/readlocks.sql derbyall fail * Generating report for RunSuite derbyall null null null true -- Java Information -- Java Version:1.5.0.03 Java Vendor: Hewlett-Packard Co. Java home: /opt/java1.5/jre Java classpath: /home/vo136787/hp/JavaDB-10.3.1.2/lib/derby.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbyTesting.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbyclient.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbynet.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbytools.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbyrun.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbyLocale_de_DE.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbyLocale_es.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbyLocale_fr.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbyLocale_it.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbyLocale_ja_JP.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbyLocale_ko_KR.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbyLocale_pt_BR.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbyLocale_zh_CN.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbyLocale_zh_TW.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/test/db2jcc.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/test/db2jcc_license_c.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/test/jakarta-oro-2.0.8.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/test/junit.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/test/jdbc2_0-stdext.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/test/jce1_2_2.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/test/geronimo-spec-jta-1.0.1B-rc4.jar:/home/vo136787/hp/JavaDB-10.3.1.2/lib/test/geronimo-spec-servlet-2.4-rc4.jar OS name: HP-UX OS architecture: PA_RISC2.0 OS version: B.11.11 Java user name: vo136787 Java user home: /home/vo136787 Java user dir: /export/home/tmp/vo136787 java.specification.name: Java Platform API Specification java.specification.version: 1.5 - Derby Information JRE - JDBC: J2SE 5.0 - JDBC 3.0 [/tmp_mnt/home/vo136787/hp/JavaDB-10.3.1.2/lib/derby.jar] 10.3.1.2 - (556213) [/tmp_mnt/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbytools.jar] 10.3.1.2 - (556213) [/tmp_mnt/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbynet.jar] 10.3.1.2 - (556213) [/tmp_mnt/home/vo136787/hp/JavaDB-10.3.1.2/lib/derbyclient.jar] 10.3.1.2 - (556213) [/tmp_mnt/home/vo136787/hp/JavaDB-10.3.1.2/lib/test/db2jcc.jar] 2.4 - (17) [/tmp_mnt/home/vo136787/hp/JavaDB-10.3.1.2/lib/test/db2jcc_license_c.jar] 2.4 - (17) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [cs] version: 10.3.1.2 - (556213) Found support for locale: [de_DE] version: 10.3.1.2 - (556213) Found support for locale: [es] version: 10.3.1.2 - (556213) Found support for locale: [fr] version: 10.3.1.2 - (556213) Found support for locale: [hu] version: 10.3.1.2 - (556213) Found support for locale: [it] version: 10.3.1.2 - (556213) Found support for locale: [ja_JP] version: 10.3.1.2 - (556213) Found support for locale: [ko_KR] version: 10.3.1.2 - (556213) Found support for locale: [pl] version: 10.3.1.2 - (556213) Found support for locale: [pt_BR] version: 10.3.1.2 - (556213) Found support for locale: [ru] version: 10.3.1.2 - (556213) Found support for locale: [zh_CN] version: 10.3.1.2 - (556213) Found support for locale: [zh_TW] version: 10.3.1.2 - (556213) -- Reporter: Henri van de Scheur Priority: Minor * Diff file derbyall/storeall/storemore/readlocks.diff *** Start: readlocks jdk1.5.0.03 storeall:storemore 2007-07-16 16:04:25 *** 18635a18636 > APP |UserTran|ROW |1 |S |A |(4,6) |GRANT|ACTIVE 18647a18649 > APP |UserTran|ROW |1 |S |A |(4,6) |GRANT|ACTIVE 18657a18660 > APP |UserTran|ROW |1 |S |A |(4,6) |GRANT|ACTIVE 18666a18670 > APP |UserTran|ROW |1 |S |A |(4,6) |GRANT|ACTIVE Test Failed. *** End: readlocks jdk1.5.0.03 storeall:storemore 2007-07-16 16:06:50 *** -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2948) Reoccurrence of DERBY-2842: derbynet/testconnection.java fails with '...Connection refused: connect' expecting 'Connection refused'
Reoccurrence of DERBY-2842: derbynet/testconnection.java fails with '...Connection refused: connect' expecting 'Connection refused' --- Key: DERBY-2948 URL: https://issues.apache.org/jira/browse/DERBY-2948 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.3.1.2 Environment: derbyall fail * derbyall/derbynetmats/derbynetmats.fail:derbynet/testconnection.java derbyall fail * Generating report for RunSuite derbyall null null null true -- Java Information -- Java Version:1.5.0_07 Java Vendor: Sun Microsystems Inc. Java home: /usr/local/java/jdk1.5.0_07/jre Java classpath: /export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/jet.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyLocale_ko_KR.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyrun.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyLocale_ja_JP.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbynet.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derby.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyLocale_zh_CN.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyclient.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyLocale_zh_TW.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyLocale_cs.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyLocale_es.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyLocale_fr.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyLocale_hu.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyLocale_it.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyLocale_pl.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbytools.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyLocale_ru.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyTesting.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyLocale_pt_BR.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyLocale_de_DE.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/jmx.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/javadbtesttools.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/activation.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/jdmkrt.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/javadbtests.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/dbprocedures.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/Perfmon.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/mail.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/jagops.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/GenCfg.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/hadbjdbc4.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/jetapi.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/commons-logging.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/db2jcc.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/jmxremote.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/db2jcc_license_c.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/jakarta-oro-2.0.8.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/Dots.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/jag.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/jmxremote_optional.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/jetbatch.jar:/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/junit.jar: OS name: Linux OS architecture: i386 OS version: 2.6.16.21-0.8-smp Java user name: jaguser Java user home: /home/jaguser Java user dir: /export/home/tmp/jagtmp/autoderbyN_derbyall/derbyall_0/log java.specification.name: Java Platform API Specification java.specification.version: 1.5 - Derby Information JRE - JDBC: J2SE 5.0 - JDBC 3.0 [/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derby.jar] 10.3.1.2 - (556213) [/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbytools.jar] 10.3.1.2 - (556213) [/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbynet.jar] 10.3.1.2 - (556213) [/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/derbyclient.jar] 10.3.1.2 - (556213) [/export/home/tmp/jagtmp/autoderbyN_derbyall/install/lib/test/db2jcc.jar] 2.4 - (17) [/export/home/tmp/jagtmp/autoderbyN_derbyall/ins
[jira] Created: (DERBY-2949) AssertionFailedError in testStalePlansOnLargeTable
AssertionFailedError in testStalePlansOnLargeTable -- Key: DERBY-2949 URL: https://issues.apache.org/jira/browse/DERBY-2949 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.3.1.2 Environment: Microsoft© Windows VistaT Ultimate - 6.0.6000 N/A Build 6000 WindowsNT 0 6 2 X [Sun Fire X4100 Server x64 Family 15 Model 37 Stepping 1 AuthenticAMD]: ~2592 MHz, cache. 3ÿ967 Total Memory. JVM: Sun Microsystems Inc. 1.5.0_07-b03 Reporter: Henri van de Scheur Priority: Minor testStalePlansOnLargeTable(org.apache.derbyTesting.functionTests.tests.lang.StalePlansTest)junit.framework.AssertionFailedError at org.apache.derbyTesting.functionTests.tests.lang.StalePlansTest.testStalePlansOnLargeTable(StalePlansTest.java:264) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2794) Document ansi trim functionality
[ https://issues.apache.org/jira/browse/DERBY-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513551 ] Øystein Grøvlen commented on DERBY-2794: I feel the introduction in the documentation is bit confusing: "TRIM is a function that returns its first string argument with leading and/or trailing pad characters removed. The second argument indicates whether leading, or trailing, or both leading and trailing pad characters should be removed. The third argument specifies the pad character that is to be removed." If argument is to mean parameter, there is only one argument as far as I can see. This argument is comprised of up to three variable parts. If argument is to mean variable part of the parameter, there are three types of arguments, but the numbering is confusing. The first argument is not necessarily the source. It is the last argument that is the source. > Document ansi trim functionality > > > Key: DERBY-2794 > URL: https://issues.apache.org/jira/browse/DERBY-2794 > Project: Derby > Issue Type: Sub-task > Components: Documentation >Affects Versions: 10.3.0.0 >Reporter: Manish Khettry >Assignee: Manish Khettry > Fix For: 10.3.0.0 > > Attachments: DERBY-2794.diff, ref-single.html, rreftrimfunc.html, > trim_doc, trim_v2.txt > > > Several examples can be found in the junit test (AnsiTrimTest). The unit test > is in java/testing/org/apache/derbyTesting/functionTests/tests/lang. > There is also the documentation from the ANSI spec which Dag had posted in a > comment in DERBY-1623. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2946) In soft upgrade mode, the metadata queries do not get compiled in SYS schema. This will cause problems in future releases of Derby.
[
https://issues.apache.org/jira/browse/DERBY-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel John Debrunner updated DERBY-2946:
-
Affects Version/s: 10.4.0.0
> In soft upgrade mode, the metadata queries do not get compiled in SYS schema.
> This will cause problems in future releases of Derby.
> ---
>
> Key: DERBY-2946
> URL: https://issues.apache.org/jira/browse/DERBY-2946
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.4.0.0
>Reporter: Mamta A. Satoor
>
> EmbedDatabaseMetaData implements metadata queries. The implementation of
> metadata queries in EmbedDatabaseMetaData checks if we are in soft upgrade
> mode (getPreparedQuery() has following code)
> if (notInSoftUpgradeMode())
> s = getPreparedQueryUsingSystemTables(queryName, net);
> else {
> try {
> //Can't use stored prepared statements because we are in soft
> upgrade
> //mode and hence need to get metadata sql from
> metadata.properties file
> //or metadata_net.properties
> String queryText = getQueryFromDescription(queryName, net);
> s = getEmbedConnection().prepareMetaDataStatement(queryText);
> } catch (Throwable t) {
> throw handleException(t);
> }
> }
> So, when running in soft upgrade mode, we do not go through SYSSTATEMENT but
> this will cause the metadata query to run in whatever the current schema may
> be rather than in SYS schema. This is not a problem in Derby 10.3 release
> because during soft upgarde, the collation will always be UCS_BASIC and hence
> collation mismatch can't happen.
> But in Derby 10.3, a user can create a database with territory based
> collation. When such a database will be in soft upgrade mode for say Derby
> 10.4, the metadata queries will run into problem if they are run in a user
> schema. This is because in soft upgrade mode, we do not go through
> SYSSTATEMENTS and instead compile the metadata queries in current schema. If
> the current schema is user schema, then character string literals in metadata
> queries will get the collation type of territory based and when compared with
> character string colunms from SYS tables with collation type of UCS_BASIC, we
> will end up getting compilation error for the metadata queries. So, before
> the next release, we will have to fix this problem. One solution may be to
> somehow make the current compilation schema as SYS when running the metadata
> queries in soft upgrade mode.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (10 issues) Subscriber: derby-dev Key Summary DERBY-2936 Use java.nio.ByteBuffer for buffering in DDMWriter https://issues.apache.org/jira/browse/DERBY-2936 DERBY-2942 Convert jdbcapi/statementJdbc30.java to JUnit https://issues.apache.org/jira/browse/DERBY-2942 DERBY-2935 DDMReader.readLengthAndCodePoint() decodes long integer incorrectly https://issues.apache.org/jira/browse/DERBY-2935 DERBY-2854 Convert jdbc4/TestResultSetMethods.java to JUnit https://issues.apache.org/jira/browse/DERBY-2854 DERBY-2798 A new approach for main-memory database https://issues.apache.org/jira/browse/DERBY-2798 DERBY-2824 Improve error reporting, fix whitespace/formatting issues and replace tabs in UTF8Reader https://issues.apache.org/jira/browse/DERBY-2824 DERBY-223 Change programs under demo directory use consistent package names so IDEs do not report errors https://issues.apache.org/jira/browse/DERBY-223 DERBY-2815 ij doesn't start with J2ME / JSR169 / weme6.1 because attempting to find java.sql.Driver if ij.protocol property is specified https://issues.apache.org/jira/browse/DERBY-2815 DERBY-2807 Create a test for BlobClob compatibility on Derby server versions vs. Derby client versions. https://issues.apache.org/jira/browse/DERBY-2807 DERBY-2255 ij should indicate that it is waiting for more input in a multi-line interactive statement. https://issues.apache.org/jira/browse/DERBY-2255
[jira] Commented: (DERBY-2940) CollationTest fail after hard upgrade from 10.2
[ https://issues.apache.org/jira/browse/DERBY-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513623 ] Mamta A. Satoor commented on DERBY-2940: I will look into this in next hr or so after I finish checking in a fix for DERBY-2896. > CollationTest fail after hard upgrade from 10.2 > --- > > Key: DERBY-2940 > URL: https://issues.apache.org/jira/browse/DERBY-2940 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.3.1.2 > Environment: Hard upgrade of 10.2 database. >Reporter: Øystein Grøvlen > > I create a database with 10.2.2.0 and then do a hard upgrade to 10.3.1.2: > > java -jar db-derby-10.2.2.0-lib/lib/derbyrun.jar ij > ij version 10.2 > ij> connect 'jdbc:derby:system/wombat;create=true'; > ij> exit; > > java -jar db-derby-10.3.1.2-bin/lib/derbyrun.jar ij > ij version 10.3 > ij> connect 'jdbc:derby:system/wombat;upgrade=true'; > ij> exit; > If I then run the CollationTest, I get: > There was 1 failure: > 1) > testDefaultCollation(org.apache.derbyTesting.functionTests.tests.lang.CollationTest)junit.framework.AssertionFailedError: > Column value mismatch @ column '1', row 1: > Expected: >UCS_BASIC< > Found:>null< > at > org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:873) > at > org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:766) > at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:704) > at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:662) > at > org.apache.derbyTesting.functionTests.tests.lang.CollationTest.checkLangBasedQuery(CollationTest.java:1014) > at > org.apache.derbyTesting.functionTests.tests.lang.CollationTest.testDefaultCollation(CollationTest.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.extensions.TestSetup.run(TestSetup.java:25) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > FAILURES!!! > Tests run: 4, Failures: 1, Errors: 0 > If I create the database with 10.3 before running the test, the tests suceeds. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Regression Test Report - Daily 556951 - Sun DBTG
[Auto-generated mail] *Daily* 556951/2007-07-17 18:00:14 CEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 3298295 072.58% derbyall 084588458 0 844.34% suitesAll sles NA NA NANA derbyall NA NA NANA suitesAll sol 3298295 078.11% derbyall UNKOWNUNKOWNUNKOWN UNKOWN 0.00% suitesAll solN+1 3298295 087.32% derbyall 084588458 0 876.47% suitesAll sparc 3298295 067.89% derbyall 084588458 0 551.80% suitesAll vista NA NA NANA derbyall NA NA NANA suitesAll w2003 3298295 0 .% derbyall F:1,E:077387737 0 157.54% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-556951.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/556951_bySig.html *Jvm: 1.5* lin 3295292 271.98% derbyall 067766776 0 503.61% suitesAll sles NA NA NANA derbyall NA NA NANA suitesAll sol 3295292 280.60% derbyall 067766776 0 483.73% suitesAll solN+1 3295292 289.22% derbyall 067766776 0 488.98% suitesAll sparc 4295291 267.93% derbyall 067766776 0 429.14% suitesAll vista NA NA NANA derbyall NA NA NANA suitesAll w2003 3295292 275.30% derbyall F:1,E:060566055 0 171.30% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-556951.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/556951_bySig.html *Jvm: 1.4* lin 3292289 473.37% derbyall 067726772 0 462.62% suitesAll sles NA NA NANA derbyall NA NA NANA suitesAll sol 3292289 478.84% derbyall 067726772 0 397.05% suitesAll solN+1 3292289 491.02% derbyall 067726772 0 465.23% suitesAll sparc 3292289 468.88% derbyall 067726772 0 446.19% suitesAll vista NA NA NANA derbyall NA NA NANA suitesAll w2003 3292289 4 .% derbyall F:1,E:060526051 0 .% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-556951.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/556951_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/556951.txt ( All results in http://dbtg.thresher.com/derby/test/ )
DERBY-581 and OLAP operations
In the context of https://issues.apache.org/jira/browse/DERBY-581 I've been studying the SQL-99 standard's specification of OLAP operations: - Feature T611 specifies "Elementary OLAP operations" - Feature T612 specifies "Advanced OLAP operations" I'm interested in exploring an implementation of these features, and to start with I'd like to get the community's reaction: - Are these features that we're interested in seeing added to Derby? - Are there others in the community who are interested in working on these features? - How could we approach this incrementally, building enough functionality to be useful, arriving at a complete implementation in pieces over time? For example, would it be reasonable to build a subset of the T611 features at first, and then expand that functionality over time? Would it be reasonable to add new SQL syntax support, but have it work only in a subset of cases, and then expand the execution functionality over time to address more usages? I was thinking that I might get started by trying to build one or more Wiki pages that describe some of the materials that might go into an implementation: - background information about the features and the concepts behind them - notes about the current Derby implementation, and about possible ways to extend the implementation in this area - ideas for how to subdivide and stage the implementation, in order to enable us to start talking about actual code. Does this seem like a reasonable approach? thanks, bryan
[jira] Commented: (DERBY-2896) DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with SQLState 42818: Comparisions between CHAR and CHAR not allowed.
[ https://issues.apache.org/jira/browse/DERBY-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513643 ] Mamta A. Satoor commented on DERBY-2896: Checked in fix for this bug in main with revision 557334. The commit changes were as follows (Myrna, can I migrate this change to 10.3 codeline?) DERBY-2896 Metadata calls getTables and getUDTs were failing when run from a user schema in a territory based collated database. The reason for it is that these metadata calls were not getting compiled in SYS schema when they were executed from a user schema. Metadata calls should always compile in SYS schema no matter what the current schema might be. The reason getTables was not getting compiled in SYS schema was because we were trying to modify it's metadata sql on the fly and then were compiling that modified sql in whatever the current schema might be. I have changed the metadata sql for getTables in metadata.properties so that we do not need to modify it on the fly anymore. This will allow getTables to follow the same codepath as other metadata queries which will also ensure that the sql gets compiled in SYS schema. As for getUDTs, it was merely a coding bug that we didn't follow the same logic as other metadata queries for it. I have changed getUDTs implementation to follow the same codepath as other metadata queries. --This line, and those below, will be ignored-- Mjava/engine/org/apache/derby/impl/jdbc/metadata.properties Mjava/engine/org/apache/derby/impl/jdbc/EmbedDatabaseMetaData.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java > DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with > SQLState 42818: Comparisions between CHAR and CHAR not allowed. > - > > Key: DERBY-2896 > URL: https://issues.apache.org/jira/browse/DERBY-2896 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.3.0.0, 10.3.1.0, 10.4.0.0 >Reporter: Daniel John Debrunner >Assignee: Mamta A. Satoor >Priority: Critical > Attachments: Test2896.zip > > > I tried adding DatabaseMetaDataTest.suite() to be run within CollationTest so > that it would test DatabaseMetaData within a collated database. > I had to fix one item in JDBC.dropSchema() where a string constant was being > compared to a system column while not in a system schema, > but with that fixed the next error hit was executing > DatabaseMetaData.getTables(). > I will add the code to collation test with the use of DatabaseMetaDataTest > commented out with this bug number. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Derby Building problems..
hi all, while I am trying to build the derby(10.3) in Fedora 7 I am getting the following problems.please help me as my two issues DERBY-2750 and DERBY-2945 are getting delayed for the same reason. Some sys info. [EMAIL PROTECTED] ~]# echo $JAVA_HOME /opt/java/j2sdk1.4.2_14 [EMAIL PROTECTED] ~]# echo $CLASSPATH .:/opt/java/j2sdk1.4.2_14/lib:/opt/java/j2sdk1.4.2_14/lib/tools.jar: /opt/java/j2sdk1.4.2_14/lib/dt.jar:/opt/java/j2sdk1.4.2_14/lib/jpda.jar: /opt/java/j2sdk1.4.2_14/jre/lib/rt.jar:/opt/java/j2sdk1.4.2_14/src.zip: /opt/junit3.8.1/junit.jar:/home/WorkSpace/DerbyGsoc/classes: /root/mysql-connector-java-3.0.17-ga/mysql-connector-java-3.0.17-ga-bin.jar :/home/WorkSpace/DerbyGsoc/java/testing/ [EMAIL PROTECTED] ~]# cat ant.properties j14lib=/usr/java/j2sdk1.4.2_14/jre/lib build.compiler=modern proceed=false sane=false [EMAIL PROTECTED] ~]# I have followed the instructions in BUILDING.txt. The Error is same i.e [EMAIL PROTECTED] DerbyGsoc]# ant Buildfile: build.xml init: ensuresanitystate: setissane: showenv: [echo] Ant environment: [echo] Base Directory: /home/WorkSpace/DerbyGsoc [echo] Build output: /home/WorkSpace/DerbyGsoc/classes [echo] Compiler: modern [echo] Sane = false [echo] Proceed = false getstate: state: shared: compile: [javac] Compiling 12 source files to /home/WorkSpace/DerbyGsoc/classes [javac] Fatal Error: Unable to locate package java.lang in classpath or bootclasspath BUILD FAILED /home/WorkSpace/DerbyGsoc/build.xml:351: The following error occurred while executing this line: /home/WorkSpace/DerbyGsoc/java/shared/build.xml:67: Compile failed; see the compiler error output for details. Total time: 2 seconds [EMAIL PROTECTED] DerbyGsoc]# On Sat, 14 Jul 2007, Ravinder Reddy wrote: On Fri, 13 Jul 2007, Andrew McIntyre wrote: On 7/13/07, Ravinder Reddy <[EMAIL PROTECTED]> wrote: Thankyou kathey. On Fri, 13 Jul 2007, Kathey Marsden wrote: > Ravinder Reddy wrote: >> >> hi, >> >> 1) how to get eclipse set up to not use tabs? >> > You can go to > Window->Preferences-> Java->Formatter-> New > give a profile name and then change the > Tab Policy to spaces only. > > To reformat your source > Source -> Format > > >> 2) recently I have migrated to a new machine in which Fedora 7 is >> installed. >> Some info regarding my system. > > Perhaps the issue is this line in your ant.properties > j14lib=$jdk14_home/jre/lib The same problem even If I give the full path.?? If you are building from inside Eclipse and get the 'Unable to find package java.lang in classpath or bootclasspath' error, make sure that the JRE system library has been added to your project classpath. Select Properties from the Project menu, then Java Build Path. You should have the JRE System Library from your JDK 1.4.2 installation listed. If not, choose Add Library... and then JRE System Library and click Next You may need to select the Alternate JRE button at this point and specify the location of your JDK 1.4.2 installation at this point. yes I have tested with JDK 1.4 and JDK 1.5 and with both.But the same error. A guide to setting up Eclipse from scratch can be found here: http://wiki.apache.org/db-derby/BuildingDerby I have followed this link only. That may also provide some useful tips to getting your Eclipse installation set up properly. best regards, andrew Thank You. -- ** Every problem that has been solved can be solved again in a better way - Ravinder Reddy *** -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Derby Building problems..
[EMAIL PROTECTED] ~]# echo $JAVA_HOME /opt/java/j2sdk1.4.2_14 [EMAIL PROTECTED] ~]# echo $CLASSPATH .:/opt/java/j2sdk1.4.2_14/lib:/opt/java/j2sdk1.4.2_14/lib/tools.jar: /opt/java/j2sdk1.4.2_14/lib/dt.jar:/opt/java/j2sdk1.4.2_14/lib/jpda.jar: /opt/java/j2sdk1.4.2_14/jre/lib/rt.jar:/opt/java/j2sdk1.4.2_14/src.zip: /opt/junit3.8.1/junit.jar:/home/WorkSpace/DerbyGsoc/classes: /root/mysql-connector-java-3.0.17-ga/mysql-connector-java-3.0.17-ga-bin.jar :/home/WorkSpace/DerbyGsoc/java/testing/ [EMAIL PROTECTED] ~]# cat ant.properties j14lib=/usr/java/j2sdk1.4.2_14/jre/lib Perhaps the j14lib value in your ant.properties should be j14lib=/opt/java/j2sdk1.4.2_14/jre/lib thanks, bryan
Re: Derby Building problems..
Thank You bryan.what a silly mistake?.In my old system I have jdk1.4 in /usr but in new system I have it in /opt.But I have been using the old ant.properties file.I have been struggling for the last 3 days for the simple mistake. n e way Thank You very much. On Wed, 18 Jul 2007, Bryan Pendleton wrote: [EMAIL PROTECTED] ~]# echo $JAVA_HOME /opt/java/j2sdk1.4.2_14 [EMAIL PROTECTED] ~]# echo $CLASSPATH .:/opt/java/j2sdk1.4.2_14/lib:/opt/java/j2sdk1.4.2_14/lib/tools.jar: /opt/java/j2sdk1.4.2_14/lib/dt.jar:/opt/java/j2sdk1.4.2_14/lib/jpda.jar: /opt/java/j2sdk1.4.2_14/jre/lib/rt.jar:/opt/java/j2sdk1.4.2_14/src.zip: /opt/junit3.8.1/junit.jar:/home/WorkSpace/DerbyGsoc/classes: /root/mysql-connector-java-3.0.17-ga/mysql-connector-java-3.0.17-ga-bin.jar :/home/WorkSpace/DerbyGsoc/java/testing/ [EMAIL PROTECTED] ~]# cat ant.properties j14lib=/usr/java/j2sdk1.4.2_14/jre/lib Perhaps the j14lib value in your ant.properties should be j14lib=/opt/java/j2sdk1.4.2_14/jre/lib thanks, bryan -- ** Every problem that has been solved can be solved again in a better way - Ravinder Reddy *** -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Regression Test Report - Daily 556951 - Sun DBTG
The last couple of days reports for suitesAll on Solaris x64 (sol) have shown 'UNKNOWN'. The JUnit test has crashed with: Exception in thread "main" java.lang.OutOfMemoryError: PermGen space Because of this there is no complete log from JUnit and the reporting scripts are unable to parse them successfully. We will have to increase the jvm's heapsize and permgen to overcome this problem. Thanks, Henri [EMAIL PROTECTED] wrote: [Auto-generated mail] *Daily* 556951/2007-07-17 18:00:14 CEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 3298295 072.58% derbyall 084588458 0 844.34% suitesAll sles NA NA NANA derbyall NA NA NANA suitesAll sol 3298295 078.11% derbyall UNKOWNUNKOWNUNKOWN UNKOWN 0.00% suitesAll solN+1 3298295 087.32% derbyall 084588458 0 876.47% suitesAll sparc 3298295 067.89% derbyall 084588458 0 551.80% suitesAll vista NA NA NANA derbyall NA NA NANA suitesAll w2003 3298295 0 .% derbyall F:1,E:077387737 0 157.54% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-556951.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/556951_bySig.html *Jvm: 1.5* lin 3295292 271.98% derbyall 067766776 0 503.61% suitesAll sles NA NA NANA derbyall NA NA NANA suitesAll sol 3295292 280.60% derbyall 067766776 0 483.73% suitesAll solN+1 3295292 289.22% derbyall 067766776 0 488.98% suitesAll sparc 4295291 267.93% derbyall 067766776 0 429.14% suitesAll vista NA NA NANA derbyall NA NA NANA suitesAll w2003 3295292 275.30% derbyall F:1,E:060566055 0 171.30% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-556951.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/556951_bySig.html *Jvm: 1.4* lin 3292289 473.37% derbyall 067726772 0 462.62% suitesAll sles NA NA NANA derbyall NA NA NANA suitesAll sol 3292289 478.84% derbyall 067726772 0 397.05% suitesAll solN+1 3292289 491.02% derbyall 067726772 0 465.23% suitesAll sparc 3292289 468.88% derbyall 067726772 0 446.19% suitesAll vista NA NA NANA derbyall NA NA NANA suitesAll w2003 3292289 4 .% derbyall F:1,E:060526051 0 .% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-556951.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/556951_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/556951.txt ( All results in http://dbtg.thresher.com/derby/test/ )
Re: Hwo to invoke a modified execute method
Dimple Bhatia <[EMAIL PROTECTED]> writes: > Hi, > I have overloaded the execute method in > org.apache.derby.impl.jdbc.EmbedStatement.execute and can call that via a > test program using the Embedded driver and that works fine.Now I want to run > Derby in network server mode and want to call this modified execute method > from the client side. In that case you need to patch the NetworkServer to use your overloaded execute when it makes calls to the embedded driver. > I see that when i create a client program to execute a > statement it calls the org.apache.derby.client.am.Statement.execute() which > calls executeX(sql) which calls flowexecute(). And i think at some time it > must be callign the EmbedStatment.execute() on the server side. Correct. But EmbedStatment.execute() will be called on the sever no matter what you do in the client. > So I thought I should overload the > org.apache.derby.client.am.Statement.execute() methods(since those > are the methodson the client side). I tried to overload the > org.apache.derby.client.am.Statement.execute() method but not sure > how to change the flowExecute() and get that working. The API seems > complicated so wondering if anyone has any ideas on how I can do > this? Not sure if Derby uses RMI(remoe method invocation) under the > covers when it invokes the execute methods on the server side. Nope, it uses DRDA (a specialized protocol for database access). It is a bit hard to give advice here, since I don't know what your overloaded execute() method looks like, but I'm guessing that you're adding parameters. The first thing you need to do is to find a way to transmit those through DRDA to the server. Then you need detect them on the sever so that the server code can figure out the execute method to use, and supply the extra parameters as required. I don't mean to discourage you, but the DRDA protocol isn't for the faint of heart (it consists of several thick volumes) and Derby's implementation of DRDA isn't really that easy to understand either, I'm afraid. It is perhaps easier to get a feel for this if you start at the sever. Start by looking at DRDAConnThread.processCommands to see how the NetworkServer converts DRDA to jdbc commands which it passes on to the embedded engine, and then converts ResultSets (and exceptions) to DRDA which it sends back to the client). HTH -- dt
[jira] Commented: (DERBY-2940) CollationTest fail after hard upgrade from 10.2
[ https://issues.apache.org/jira/browse/DERBY-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513677 ] Mamta A. Satoor commented on DERBY-2940: Oystein, I did some research into this issue. The failure in the CollationTest on a hard-upgraded pre-10.3 database is because we are testing the derby.database.collation property of the database and expecting it to be UCS_BASIC. But in a hard-upgraded database, this property does not exist and hence we get NULL rather than UCS_BASIC. More info below. This behavior is based on the decision made in following thread http://www.nabble.com/Should-COLLATION-attribute-related-code-go-in-BasicDatabase--tf3397113.html#a9496608 (Mike's mail on March 21st 2007 had raised the question of what would happen if no derby.database.collation property is found in soft upgrade mode. We had to code such that in soft upgrade mode, we should be able to interpret pre-10.3 databases to have a collation of UCS_BASIC when no derby.database.collation exists. And hence to make the code work for both soft and hard upgrade mode, we decided not to add derby.database.collation property with value of UCS_BASIC) So, the behavior you are noticing of derby.database.collation property having a value of NULL after a hard upgrade of pre-10.3 database is expected behavior. In my codeline, I changed the CollationTest to comment out checking of derby.database.collation value and then the rest of the test ran fine on a hard-upgraded database. Please let me know if you have further questions. > CollationTest fail after hard upgrade from 10.2 > --- > > Key: DERBY-2940 > URL: https://issues.apache.org/jira/browse/DERBY-2940 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.3.1.2 > Environment: Hard upgrade of 10.2 database. >Reporter: Øystein Grøvlen >Assignee: Mamta A. Satoor > > I create a database with 10.2.2.0 and then do a hard upgrade to 10.3.1.2: > > java -jar db-derby-10.2.2.0-lib/lib/derbyrun.jar ij > ij version 10.2 > ij> connect 'jdbc:derby:system/wombat;create=true'; > ij> exit; > > java -jar db-derby-10.3.1.2-bin/lib/derbyrun.jar ij > ij version 10.3 > ij> connect 'jdbc:derby:system/wombat;upgrade=true'; > ij> exit; > If I then run the CollationTest, I get: > There was 1 failure: > 1) > testDefaultCollation(org.apache.derbyTesting.functionTests.tests.lang.CollationTest)junit.framework.AssertionFailedError: > Column value mismatch @ column '1', row 1: > Expected: >UCS_BASIC< > Found:>null< > at > org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:873) > at > org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:766) > at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:704) > at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:662) > at > org.apache.derbyTesting.functionTests.tests.lang.CollationTest.checkLangBasedQuery(CollationTest.java:1014) > at > org.apache.derbyTesting.functionTests.tests.lang.CollationTest.testDefaultCollation(CollationTest.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.extensions.TestSetup.run(TestSetup.java:25) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > FAILURES!!! > Tests run: 4, Failures: 1, Errors: 0 > If I create the database with 10.3 before running the test, the tests suceeds. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2896) DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with SQLState 42818: Comparisions between CHAR and CHAR not allowed.
[ https://issues.apache.org/jira/browse/DERBY-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513678 ] Knut Anders Hatlen commented on DERBY-2896: --- I haven't followed this discussion closely, but I'd just mention that before you port the fix to 10.3, you might want to have a look at http://wiki.apache.org/db-derby/MetadataUpgrade, the section about Maintenance and Point Releases in particular. The changes in metadata.properties will not be picked up when you upgrade from 10.3.1.x to 10.3.2.x. I don't know if that's a problem, but you may have to do something more exotic to make it work in that scenario. > DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with > SQLState 42818: Comparisions between CHAR and CHAR not allowed. > - > > Key: DERBY-2896 > URL: https://issues.apache.org/jira/browse/DERBY-2896 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.3.0.0, 10.3.1.0, 10.4.0.0 >Reporter: Daniel John Debrunner >Assignee: Mamta A. Satoor >Priority: Critical > Attachments: Test2896.zip > > > I tried adding DatabaseMetaDataTest.suite() to be run within CollationTest so > that it would test DatabaseMetaData within a collated database. > I had to fix one item in JDBC.dropSchema() where a string constant was being > compared to a system column while not in a system schema, > but with that fixed the next error hit was executing > DatabaseMetaData.getTables(). > I will add the code to collation test with the use of DatabaseMetaDataTest > commented out with this bug number. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2940) CollationTest fail after hard upgrade from 10.2
[ https://issues.apache.org/jira/browse/DERBY-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor reassigned DERBY-2940: -- Assignee: Mamta A. Satoor > CollationTest fail after hard upgrade from 10.2 > --- > > Key: DERBY-2940 > URL: https://issues.apache.org/jira/browse/DERBY-2940 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.3.1.2 > Environment: Hard upgrade of 10.2 database. >Reporter: Øystein Grøvlen >Assignee: Mamta A. Satoor > > I create a database with 10.2.2.0 and then do a hard upgrade to 10.3.1.2: > > java -jar db-derby-10.2.2.0-lib/lib/derbyrun.jar ij > ij version 10.2 > ij> connect 'jdbc:derby:system/wombat;create=true'; > ij> exit; > > java -jar db-derby-10.3.1.2-bin/lib/derbyrun.jar ij > ij version 10.3 > ij> connect 'jdbc:derby:system/wombat;upgrade=true'; > ij> exit; > If I then run the CollationTest, I get: > There was 1 failure: > 1) > testDefaultCollation(org.apache.derbyTesting.functionTests.tests.lang.CollationTest)junit.framework.AssertionFailedError: > Column value mismatch @ column '1', row 1: > Expected: >UCS_BASIC< > Found:>null< > at > org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:873) > at > org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:766) > at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:704) > at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:662) > at > org.apache.derbyTesting.functionTests.tests.lang.CollationTest.checkLangBasedQuery(CollationTest.java:1014) > at > org.apache.derbyTesting.functionTests.tests.lang.CollationTest.testDefaultCollation(CollationTest.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.extensions.TestSetup.run(TestSetup.java:25) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > FAILURES!!! > Tests run: 4, Failures: 1, Errors: 0 > If I create the database with 10.3 before running the test, the tests suceeds. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (DERBY-2896) DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with SQLState 42818: Comparisions between CHAR and CHAR not allowed.
On 7/18/07, Mamta A. Satoor (JIRA) <[EMAIL PROTECTED]> wrote: Myrna, can I migrate this change to 10.3 codeline? There was a discussion about this recently, can't find the thread right now, but basically, I can't really stop anyone from checking in...If the committer feels a high degree of confidence in the fix, they should check it in, with some regard for the short timeframe that the release manager is actually building the artifacts & bumping versions and the like. :-) So thank you for checking - I'm not currently doing any build processes, so there's nothing I need that would stop you... Furthermore, in this case, this was one of the critical issues I'd have preferred to be fixed *before* I made the 10.3.1.2 release... Myrna
regarding unique keys in derby..
hi all, w.r.t DERBY-2945(convert lang/primarykey.sql to junit) I have a small doubt. There is a test for verifying a unique key can not contain nulls. 1)-- verify that a unique key can not contain nulls create table pos1 (c1 int not null unique, c2 int); insert into pos1 (c1) values(null); insert into pos1 (c1) values(null); select * from pos1; drop table pos1; And It tests that null values are not allowed in c1. Irrespective of uniqueness , c1 can't contain null values as it is defined as not null.It seems that the test is wrong. 2) I am shocked to know that Derby doesn't allow a unique key column to contain NULL values.can some somebody justify it.? Thank You. -- ** Every problem that has been solved can be solved again in a better way - Ravinder Reddy *** -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
[jira] Commented: (DERBY-2896) DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with SQLState 42818: Comparisions between CHAR and CHAR not allowed.
[ https://issues.apache.org/jira/browse/DERBY-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513688 ] Kathey Marsden commented on DERBY-2896: --- >The changes in metadata.properties will not be picked up when you upgrade from >10.3.1.x to 10.3.2.x. This filed as DERBY-1107 and I think is a good reason to have a new release candidate. I think other critical issues such as DERBY-2437 and the regression DERBY-2892 might be worth waiting for too if they can be fixed in short order. I wouldn't veto a release at this point but would probably vote -0. > DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with > SQLState 42818: Comparisions between CHAR and CHAR not allowed. > - > > Key: DERBY-2896 > URL: https://issues.apache.org/jira/browse/DERBY-2896 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.3.0.0, 10.3.1.0, 10.4.0.0 >Reporter: Daniel John Debrunner >Assignee: Mamta A. Satoor >Priority: Critical > Attachments: Test2896.zip > > > I tried adding DatabaseMetaDataTest.suite() to be run within CollationTest so > that it would test DatabaseMetaData within a collated database. > I had to fix one item in JDBC.dropSchema() where a string constant was being > compared to a system column while not in a system schema, > but with that fixed the next error hit was executing > DatabaseMetaData.getTables(). > I will add the code to collation test with the use of DatabaseMetaDataTest > commented out with this bug number. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-581) Modify SQL to skip N rows of the result and return the next M rows
[
https://issues.apache.org/jira/browse/DERBY-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Pendleton reassigned DERBY-581:
-
Assignee: Bryan Pendleton
> Modify SQL to skip N rows of the result and return the next M rows
> --
>
> Key: DERBY-581
> URL: https://issues.apache.org/jira/browse/DERBY-581
> Project: Derby
> Issue Type: New Feature
> Components: SQL
> Environment: All
>Reporter: Craig Russell
>Assignee: Bryan Pendleton
>Priority: Minor
>
> I agree that the information should be expressed in SQL so that the query
> optimized and execution strategy can know what the user needs in terms of
> cardinality.
> I'd also like to ask that when we consider extending the SQL in this manner
> we consider skipping the first N rows and returning the next M rows.
> Craig
> On Sep 20, 2005, at 10:19 AM, Suavi Ali Demir wrote:
> Another little detail about optimization is that Statement.setMaxRows() kind
> of functions on the JDBC side may not be sufficient since it is called after
> SQL statement is prepared and returned as an object (after query plan is
> built). Therefore, it may be necessary to have language syntax to indicate
> the intention to fetch first 1000 rows only, so that when the query is
> prepared, this intention can be taken into account.
> Regards,
> Ali
> Mike Matrigali <[EMAIL PROTECTED]> wrote:
> As craig points out it is important in performance testing to say
> exactly what you are measuring. In general Derby will try to
> stream rows to the user before it has finished looking at all rows.
> So often looking at the first row will and stopping will mean that
> many rows have not been processed. BUT when an order by is involved
> and the query plan either has no appropriate matching index, or decides
> to use a different index then all the rows are processed, then they are
> sent to the sorter and finally after all rows are processed they are
> streamed to the client.
> So as you have seen reading the first 1000 rows of a much larger data
> set can happen very quickly.
> As subsequent mail threads have pointed out, returning the top 1000
> sorted rows is an interesting problem which could be costed and executed
> differently if that information was pushed into the optimizer and the
> sorter (and medium level projects were done in those areas).
> > On Sep 16, 2005, at 4:42 PM, Scott Ogden wrote:
> >
> >
> >
> > I have observed some interesting query performance behavior and am
> > hoping someone here can explain.
> >
> > In my scenario, it appears that an existing index is not being used for
> > the 'order by' part of the operation and as a result the perfo rmance of
> > certain queries is suffering. Can someone explain if this is supposed
> > to be what is happening and why? Please see below for the specific
> > queries and their performance characteristics.
> >
> > Here are the particulars:
> >
> > -
> >
> > create table orders(
> >
> > order_id varchar(50) NOT NULL
> >
> > CONSTRAINT ORDERS_PK PRIMARY KEY,
> >
> > amount numeric(31,2),
> >
> > time date,
> >
> > inv_num varchar(50),
> >
> > line_num varchar(50),
> >
> > phone varchar(50),
> >
> > prod_num varchar(50));
> > > --Load a large amount of data (720,000 records) into the 'orders' table
> > >
> > --Create an index on the time column as that will be used i n the 'where'
> > clause.
> >
> > create index IX_ORDERS_TIME on orders(time);
> > >
> > --When I run a query against this table returning top 1,000 records,
> > this query returns very quickly, consistently less than .010 seconds.
> >>
> >>
> >> select * from orders
> >>
> >> where time > '10/01/2002' and time < '11/30/2002'
> >>
> >> order by time;
> >>
> >> --Now run a similarly query against same table, returning the top
> >> 1,000 records.
> >>
> >> --The difference is that the results are now sorted by the primary key
> >> ('order_id') rather than 'time'.
> >>
> >> --This query returns slowly, approximately 15 seconds. Why??
> >>
> >> select * from orders
> >>
> >> where time > '10/01/2002' and time < '11/30/2002'
> >>
> >> order by order_id;
> >>
> >> --Now run a third query against the same 'orders' table, removing the
> >> where clause
> >>
> >> --This query returns quickly, around .010 seconds.
> >>
> >>
> >>
> >> select * from orders
> >>
> >> order by order_id;
> >>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
again, another 10.3.1. release candidate?
Hi, There was a discussion ensuing from DERBY-2896, which I think should be a general discussion item, following mamta's check-in for a fix for that critical issue. Knut Anders Wrote: >The changes in metadata.properties will not be picked up when you upgrade from 10.3.1.x to 10.3.2.x. Kathey replied: This filed as DERBY-1107 and I think is a good reason to have a new release candidate. I think other critical issues such as DERBY-2437 and the regression DERBY-2892 might be worth waiting for too if they can be fixed in short order. I wouldn't veto a release at this point but would probably vote -0. It seems to me that even though Kathey doesn't want to hold up the release, she really doesn't want a release without this fix. Which to me sounds like a new release candidate, which, as we've got a vote outstanding, means holding up the release. :-) But Kathey's email poses some options 1. I can do a fairly quick turn-around and make another release candidate after Mamta backports the fix to 10.3. If I can build the files tonight or tomorrow morning early, I can test, and call a vote around noon, that would give us until July 26th noon (PDT) and I could maybe still close the vote and hope that the maven work and web page work can be finished on that day, or leave it to Rick to do that part once he's back the week after. 2. We can wait until someone fixes DERBY-2892 for 10.3. I have not heard anything positive, nor a time frame for such a fix. If a fix happens before the 26th, I can generate new build files and open the voting, but someone else (Rick when he's back form vacation/conference?) will have to finish up the work for this release. 3. We can wait even further until other critical issues such as DERBY-2437 are fixed. I want to point out, that no has volunteered to own that one at this point, so we might be waiting indefinitely. I can, as I have suggested before, pick up the release work in September, and we can see how far the fixes are then. Or someone else can volunteer. Kathey, please be explicit, which 'other' issues except DERBY-2437 do you think are necessary to receive a fix? Myrna
Regression Test Report - tinderbox_trunk16 557291 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 557291/2007-07-18 17:22:18 CEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 3298295 0 169.71% derbyall 084588458 0 1832.26% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-557291.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/557291_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/557291.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Resolved: (DERBY-1806) Connection errors in 10.2.1.1 - not seen in 10.1.2.1
[ https://issues.apache.org/jira/browse/DERBY-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-1806. --- Resolution: Cannot Reproduce > Connection errors in 10.2.1.1 - not seen in 10.1.2.1 > > > Key: DERBY-1806 > URL: https://issues.apache.org/jira/browse/DERBY-1806 > Project: Derby > Issue Type: Bug > Components: Network Client, Network Server >Affects Versions: 10.2.1.6 > Environment: WinXP 2G RAM 2.8 GHz dual PIV >Reporter: Prasenjit Sarkar > > Essentially the Derby 10.2 beta is unable to handle multiple connections to > it - when we have a large number of connections to the db, we get stale > connection errors, not observed in 10.1 > Details from our test team: > The problem I am running into is that if I submit two storage subsystem > probes at the same time, the jobs may not finish and show the following errors > 8/31/06 3:33:11 PM SRV0044E: Unable to connect to repository database. > Please ensure that the repository database is up > and running. > Driver: [EMAIL PROTECTED] > URL : jdbc:derby://tivoli14:1527/Aperi > SQLSTATE: 08001, Vendor error code: -4499 > java.net.BindException : Error connecting to server > tivoli14 on port 1527 with message Address already in use: connect. > 8/31/06 3:33:11 PM STS0079E: Unable to run job ExecProbeSS. > I think the problem is critical enough and should be fixed ASAP. > > Thu Aug 31 15:32:52 PDT 2006 Stale connection encountered = [EMAIL PROTECTED] > Thu Aug 31 15:33:03 PDT 2006 > java.sql.SQLException: java.net.BindException : Error connecting to server > tivoli14 on port 1527 with message Address already in use: connect. > at > org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) > at org.apache.derby.client.am.SqlException.getSQLException(Unknown > Source) > at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source) > at > org.eclipse.aperi.infrastructure.database.Database.getConnection(Database.java:300) > at > org.eclipse.aperi.infrastructure.database.Database.getConnection(Database.java:267) > at > org.eclipse.aperi.infrastructure.database.DBConnPoolDataSource$Pool.remove(DBConnPoolDataSource.java:306) > at > org.eclipse.aperi.infrastructure.database.DBConnPoolDataSource.getPooledConnection(DBConnPoolDataSource.java:110) > at org.eclipse.aperi.ServiceUtils.getConnection(ServiceUtils.java:314) > at > org.eclipse.aperi.snmpagent.manager.SNMPAgentManager.getTargets(SNMPAgentManager.java:647) > at > org.eclipse.aperi.snmpagent.manager.SNMPAgentManager.refreshAllIpTargetCapabilities(SNMPAgentManager.java:988) > at > org.eclipse.aperi.snmpagent.manager.SNMPAgentManager.run(SNMPAgentManager.java:1694) > at java.lang.Thread.run(Unknown Source) > Caused by: org.apache.derby.client.am.DisconnectException: > java.net.BindException : Error connecting to server tivoli14 on port 1527 > with message Address already in use: connect. > at org.apache.derby.client.net.NetAgent.(Unknown Source) > at org.apache.derby.client.net.NetConnection.newAgent_(Unknown Source) > at org.apache.derby.client.am.Connection.(Unknown Source) > at org.apache.derby.client.net.NetConnection.(Unknown Source) > at > org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetConnection(Unknown > Source) > ... 10 more > Caused by: java.net.BindException: Address already in use: connect > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(Unknown Source) > at java.net.PlainSocketImpl.connectToAddress(Unknown Source) > at java.net.PlainSocketImpl.connect(Unknown Source) > at java.net.SocksSocketImpl.connect(Unknown Source) > at java.net.Socket.connect(Unknown Source) > at java.net.Socket.connect(Unknown Source) > at java.net.Socket.(Unknown Source) > at java.net.Socket.(Unknown Source) > at org.apache.derby.client.net.OpenSocketAction.run(Unknown Source) > at java.security.AccessController.doPrivileged(Native Method) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: DERBY-581 and OLAP operations
Bryan, It sounds like a very reasonable and thoughtful way to get started. One thing which is frustrating about working with Derby is that large portions of the code are so very cryptic and brittle, sometimes unnceccsarily so. Having more than one person try and understand relevant code, documenting it and sharing this information would help in more ways than one. The other thing-- is it possible to get a hold of the relevant portions of the SQL standard that you refer to? m On 7/18/07, Bryan Pendleton <[EMAIL PROTECTED]> wrote: In the context of https://issues.apache.org/jira/browse/DERBY-581 I've been studying the SQL-99 standard's specification of OLAP operations: - Feature T611 specifies "Elementary OLAP operations" - Feature T612 specifies "Advanced OLAP operations" I'm interested in exploring an implementation of these features, and to start with I'd like to get the community's reaction: - Are these features that we're interested in seeing added to Derby? - Are there others in the community who are interested in working on these features? - How could we approach this incrementally, building enough functionality to be useful, arriving at a complete implementation in pieces over time? For example, would it be reasonable to build a subset of the T611 features at first, and then expand that functionality over time? Would it be reasonable to add new SQL syntax support, but have it work only in a subset of cases, and then expand the execution functionality over time to address more usages? I was thinking that I might get started by trying to build one or more Wiki pages that describe some of the materials that might go into an implementation: - background information about the features and the concepts behind them - notes about the current Derby implementation, and about possible ways to extend the implementation in this area - ideas for how to subdivide and stage the implementation, in order to enable us to start talking about actual code. Does this seem like a reasonable approach? thanks, bryan
Re: again, another 10.3.1. release candidate?
Hi Myrna! I understand your concern and would like to share my thoughts. I think a combination of 1) and 3) would be best. I would prefer a release now, but understand the concerns in the community and thereby the need for a new RC. After the 26th I will also start a vacation, so that would suit me fine (just in time). When we know that an update release will be started on in September, I guess that will also make it easier to accept some other critical issues in this RC. Thanks! Henri PS: I hope to post results of testing on 10.3.1.2 tomorrow. As far as I have seen so far, it looks quite good. Myrna van Lunteren wrote: Hi, There was a discussion ensuing from DERBY-2896, which I think should be a general discussion item, following mamta's check-in for a fix for that critical issue. Knut Anders Wrote: >The changes in metadata.properties will not be picked up when you upgrade from 10.3.1.x to 10.3.2.x. Kathey replied: This filed as DERBY-1107 and I think is a good reason to have a new release candidate. I think other critical issues such as DERBY-2437 and the regression DERBY-2892 might be worth waiting for too if they can be fixed in short order. I wouldn't veto a release at this point but would probably vote -0. It seems to me that even though Kathey doesn't want to hold up the release, she really doesn't want a release without this fix. Which to me sounds like a new release candidate, which, as we've got a vote outstanding, means holding up the release. :-) But Kathey's email poses some options 1. I can do a fairly quick turn-around and make another release candidate after Mamta backports the fix to 10.3. If I can build the files tonight or tomorrow morning early, I can test, and call a vote around noon, that would give us until July 26th noon (PDT) and I could maybe still close the vote and hope that the maven work and web page work can be finished on that day, or leave it to Rick to do that part once he's back the week after. 2. We can wait until someone fixes DERBY-2892 for 10.3. I have not heard anything positive, nor a time frame for such a fix. If a fix happens before the 26th, I can generate new build files and open the voting, but someone else (Rick when he's back form vacation/conference?) will have to finish up the work for this release. 3. We can wait even further until other critical issues such as DERBY-2437 are fixed. I want to point out, that no has volunteered to own that one at this point, so we might be waiting indefinitely. I can, as I have suggested before, pick up the release work in September, and we can see how far the fixes are then. Or someone else can volunteer. Kathey, please be explicit, which 'other' issues except DERBY-2437 do you think are necessary to receive a fix? Myrna
Re: again, another 10.3.1. release candidate?
In my openion we should go for a release (if we can include Mamta's fix, that will be great). But not to wait for the bugs which are not picked by anyone. And then may be in September we can have a bugfix release. As far, for me RC2 tests are progressing well. So nothing stops me to vote +1 Thanks Manjula On 7/18/07, Henri van de Scheur - Sun Norway <[EMAIL PROTECTED]> wrote: Hi Myrna! I understand your concern and would like to share my thoughts. I think a combination of 1) and 3) would be best. I would prefer a release now, but understand the concerns in the community and thereby the need for a new RC. After the 26th I will also start a vacation, so that would suit me fine (just in time). When we know that an update release will be started on in September, I guess that will also make it easier to accept some other critical issues in this RC. Thanks! Henri PS: I hope to post results of testing on 10.3.1.2 tomorrow. As far as I have seen so far, it looks quite good. Myrna van Lunteren wrote: > Hi, > > There was a discussion ensuing from DERBY-2896, which I think should > be a general discussion item, following mamta's check-in for a fix for > that critical issue. > > > Knut Anders Wrote: >> >The changes in metadata.properties will not be picked up when you >> upgrade from 10.3.1.x to 10.3.2.x. >> > Kathey replied: >> This filed as DERBY-1107 and I think is a good reason to have a new >> release candidate. I think other critical issues such as DERBY-2437 >> and the regression DERBY-2892 might be worth waiting for too if they >> can be fixed in short order. I wouldn't veto a release at this point >> but would probably vote -0. > > > It seems to me that even though Kathey doesn't want to hold up the > release, she really doesn't want a release without this fix. > Which to me sounds like a new release candidate, which, as we've got a > vote outstanding, means holding up the release. :-) > > But Kathey's email poses some options > 1. I can do a fairly quick turn-around and make another release > candidate after Mamta backports the fix to 10.3. If I can build the > files tonight or tomorrow morning early, I can test, and call a vote > around noon, that would give us until July 26th noon (PDT) and I could > maybe still close the vote and hope that the maven work and web page > work can be finished on that day, or leave it to Rick to do that part > once he's back the week after. > > 2. We can wait until someone fixes DERBY-2892 for 10.3. I have not > heard anything positive, nor a time frame for such a fix. If a fix > happens before the 26th, I can generate new build files and open the > voting, but someone else (Rick when he's back form > vacation/conference?) will have to finish up the work for this > release. > > 3. We can wait even further until other critical issues such as > DERBY-2437 are fixed. I want to point out, that no has volunteered to > own that one at this point, so we might be waiting indefinitely. I > can, as I have suggested before, pick up the release work in > September, and we can see how far the fixes are then. Or someone else > can volunteer. > > Kathey, please be explicit, which 'other' issues except DERBY-2437 do > you think are necessary to receive a fix? > > > Myrna -- Thanks, Manjula.
Re: again, another 10.3.1. release candidate?
Myrna, I have run critical tests on my 10.3 codeline after merge and things are running fine so far. I will go ahead and back port my changes into 10.3codeline because I will be gone for the rest of the evening and in case we decide to cut a 10.3.1.x branch before that. I will tackle the metadata upgrade issue only if it turns out that my changes will not make into 10.3.1.x Mamta On 7/18/07, Myrna van Lunteren <[EMAIL PROTECTED]> wrote: Hi, There was a discussion ensuing from DERBY-2896, which I think should be a general discussion item, following mamta's check-in for a fix for that critical issue. Knut Anders Wrote: > >The changes in metadata.properties will not be picked up when you upgrade from 10.3.1.x to 10.3.2.x. > Kathey replied: > This filed as DERBY-1107 and I think is a good reason to have a new release candidate. I think other critical issues such as DERBY-2437 and the regression DERBY-2892 might be worth waiting for too if they can be fixed in short order. I wouldn't veto a release at this point but would probably vote -0. It seems to me that even though Kathey doesn't want to hold up the release, she really doesn't want a release without this fix. Which to me sounds like a new release candidate, which, as we've got a vote outstanding, means holding up the release. :-) But Kathey's email poses some options 1. I can do a fairly quick turn-around and make another release candidate after Mamta backports the fix to 10.3 . If I can build the files tonight or tomorrow morning early, I can test, and call a vote around noon, that would give us until July 26th noon (PDT) and I could maybe still close the vote and hope that the maven work and web page work can be finished on that day, or leave it to Rick to do that part once he's back the week after. 2. We can wait until someone fixes DERBY-2892 for 10.3. I have not heard anything positive, nor a time frame for such a fix. If a fix happens before the 26th, I can generate new build files and open the voting, but someone else (Rick when he's back form vacation/conference?) will have to finish up the work for this release. 3. We can wait even further until other critical issues such as DERBY-2437 are fixed. I want to point out, that no has volunteered to own that one at this point, so we might be waiting indefinitely. I can, as I have suggested before, pick up the release work in September, and we can see how far the fixes are then. Or someone else can volunteer. Kathey, please be explicit, which 'other' issues except DERBY-2437 do you think are necessary to receive a fix? Myrna
[jira] Created: (DERBY-2950) BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with exception: java.sql.SQLException: Operand of LIKE predicate with type VARCHAR(128) and collation U
BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with exception: java.sql.SQLException: Operand of LIKE predicate with type VARCHAR(128) and collation UCS_BASIC is not compatable with LIKE pattern operand with type CHAR(4) and collation --- Key: DERBY-2950 URL: https://issues.apache.org/jira/browse/DERBY-2950 Project: Derby Issue Type: Bug Affects Versions: 10.4.0.0 Reporter: Kathey Marsden BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with exception: java.sql.SQLException: Operand of LIKE predicate with type VARCHAR(128) and collation UCS_BASIC is not compatable with LIKE pattern operand with type CHAR(4) and collation Full trace below: java.sql.SQLException: Operand of LIKE predicate with type VARCHAR(128) and collation UCS_BASIC is not compatable with LIKE pattern operand with type CHAR(4) and collation TERRITORY_BASED. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:202) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:391) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1572) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:585) at org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java:153) at org.apache.derbyTesting.functionTests.tests.jdbcapi.BatchUpdateTest.testMinimalDDLInBatch(BatchUpdateTest.java:248) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.ex
[jira] Updated: (DERBY-2950) BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with exception: java.sql.SQLException: Operand of LIKE predicate with type VARCHAR(128) and collation U
[ https://issues.apache.org/jira/browse/DERBY-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2950: -- Component/s: SQL > BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with > exception: java.sql.SQLException: Operand of LIKE predicate with type > VARCHAR(128) and collation UCS_BASIC is not compatable with LIKE pattern > operand with type CHAR(4) and collation > --- > > Key: DERBY-2950 > URL: https://issues.apache.org/jira/browse/DERBY-2950 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden > > BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with > exception: java.sql.SQLException: Operand of LIKE predicate with type > VARCHAR(128) and collation UCS_BASIC is not compatable with LIKE pattern > operand with type CHAR(4) and collation > Full trace below: > java.sql.SQLException: Operand of LIKE predicate with type VARCHAR(128) and > collation UCS_BASIC is not compatable with LIKE pattern operand with type > CHAR(4) and collation TERRITORY_BASED. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) > at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:202) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:391) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) > at > org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1572) > at > org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:585) > at > org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java:153) > at > org.apache.derbyTesting.functionTests.tests.jdbcapi.BatchUpdateTest.testMinimalDDLInBatch(BatchUpdateTest.java:248) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:615) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java
[jira] Commented: (DERBY-2896) DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with SQLState 42818: Comparisions between CHAR and CHAR not allowed.
[ https://issues.apache.org/jira/browse/DERBY-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513729 ] Mamta A. Satoor commented on DERBY-2896: Ported the changes from main into 10.3 codeline (revision 557405) Will look into metadata upgrade issue if it turns out that my changes didn't make into 10.3.1.x codeline. > DatabaseMetaData.getTables() fails in TERRORITY_BASED collation database with > SQLState 42818: Comparisions between CHAR and CHAR not allowed. > - > > Key: DERBY-2896 > URL: https://issues.apache.org/jira/browse/DERBY-2896 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.3.0.0, 10.3.1.0, 10.4.0.0 >Reporter: Daniel John Debrunner >Assignee: Mamta A. Satoor >Priority: Critical > Attachments: Test2896.zip > > > I tried adding DatabaseMetaDataTest.suite() to be run within CollationTest so > that it would test DatabaseMetaData within a collated database. > I had to fix one item in JDBC.dropSchema() where a string constant was being > compared to a system column while not in a system schema, > but with that fixed the next error hit was executing > DatabaseMetaData.getTables(). > I will add the code to collation test with the use of DatabaseMetaDataTest > commented out with this bug number. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2951) BatchUpdateTest.testAssociatedParams test fails with collation with exception: java.sql.SQLException: Java exception: 'ASSERT FAILED type of inserted column[0] = org.apach
BatchUpdateTest.testAssociatedParams test fails with collation with exception: java.sql.SQLException: Java exception: 'ASSERT FAILED type of inserted column[0] = org.apache.derby.iapi.types.CollatorSQLChartype of template column[0] = org.apache.derby. --- Key: DERBY-2951 URL: https://issues.apache.org/jira/browse/DERBY-2951 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.0.0 Reporter: Kathey Marsden BatchUpdateTest.testAssociatedParams test fails with collation with exception: java.sql.SQLException: Java exception: 'ASSERT FAILED type of inserted column[0] = org.apache.derby.iapi.types.CollatorSQLChartype of template column[0] = org.apache.derby.iapi.types.SQLChar: org.apache.derby.shared.common.sanity.AssertFailure'. Full trace below: Java exception: 'ASSERT FAILED type of inserted column[0] = org.apache.derby.iapi.types.CollatorSQLChartype of template column[0] = org.apache.derby.iapi.types.SQLChar: org.apache.derby.shared.common.sanity.AssertFailure'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:88) at org.apache.derby.impl.jdbc.Util.javaException(Util.java:245) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1572) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1293) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1652) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:299) at org.apache.derbyTesting.functionTests.tests.jdbcapi.BatchUpdateTest.testAssociatedParams(BatchUpdateTest.java:416) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(Te
[jira] Updated: (DERBY-2951) BatchUpdateTest.testAssociatedParams test fails with collation with exception: Java exception: 'ASSERT FAILED type of inserted column[0] = org.apache.derby.iapi.types.Coll
[ https://issues.apache.org/jira/browse/DERBY-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2951: -- Summary: BatchUpdateTest.testAssociatedParams test fails with collation with exception: Java exception: 'ASSERT FAILED type of inserted column[0] = org.apache.derby.iapi.types.CollatorSQLChartype of template column[0] = org.apache.derby.iapi.types.SQLChar: (was: BatchUpdateTest.testAssociatedParams test fails with collation with exception: java.sql.SQLException: Java exception: 'ASSERT FAILED type of inserted column[0] = org.apache.derby.iapi.types.CollatorSQLChartype of template column[0] = org.apache.derby.) > BatchUpdateTest.testAssociatedParams test fails with collation with > exception: Java exception: 'ASSERT FAILED type of inserted column[0] = > org.apache.derby.iapi.types.CollatorSQLChartype of template column[0] = > org.apache.derby.iapi.types.SQLChar: > > > Key: DERBY-2951 > URL: https://issues.apache.org/jira/browse/DERBY-2951 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden > > BatchUpdateTest.testAssociatedParams test fails with collation with > exception: java.sql.SQLException: Java exception: 'ASSERT FAILED type of > inserted column[0] = org.apache.derby.iapi.types.CollatorSQLChartype of > template column[0] = org.apache.derby.iapi.types.SQLChar: > org.apache.derby.shared.common.sanity.AssertFailure'. > Full trace below: > Java exception: 'ASSERT FAILED type of inserted column[0] = > org.apache.derby.iapi.types.CollatorSQLChartype of template column[0] = > org.apache.derby.iapi.types.SQLChar: > org.apache.derby.shared.common.sanity.AssertFailure'. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:88) > at org.apache.derby.impl.jdbc.Util.javaException(Util.java:245) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) > at > org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1572) > at > org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) > at > org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1293) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1652) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:299) > at > org.apache.derbyTesting.functionTests.tests.jdbcapi.BatchUpdateTest.testAssociatedParams(BatchUpdateTest.java:416) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:615) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
[jira] Commented: (DERBY-2950) BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with exception: java.sql.SQLException: Operand of LIKE predicate with type VARCHAR(128) and collation
[ https://issues.apache.org/jira/browse/DERBY-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513730 ] Mamta A. Satoor commented on DERBY-2950: Kathey, I won't have time until later this evening to look into this but how do you run BatchUpdateTest with collation? > BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with > exception: java.sql.SQLException: Operand of LIKE predicate with type > VARCHAR(128) and collation UCS_BASIC is not compatable with LIKE pattern > operand with type CHAR(4) and collation > --- > > Key: DERBY-2950 > URL: https://issues.apache.org/jira/browse/DERBY-2950 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden > > BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with > exception: java.sql.SQLException: Operand of LIKE predicate with type > VARCHAR(128) and collation UCS_BASIC is not compatable with LIKE pattern > operand with type CHAR(4) and collation > Full trace below: > java.sql.SQLException: Operand of LIKE predicate with type VARCHAR(128) and > collation UCS_BASIC is not compatable with LIKE pattern operand with type > CHAR(4) and collation TERRITORY_BASED. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) > at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:202) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:391) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) > at > org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1572) > at > org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:585) > at > org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java:153) > at > org.apache.derbyTesting.functionTests.tests.jdbcapi.BatchUpdateTest.testMinimalDDLInBatch(BatchUpdateTest.java:248) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:615) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.apac
Re: DERBY-581 and OLAP operations
Hi Manish, thank you very much for the encouraging words. I agree that the more people who get familiar with the code and the implementation, the better it is. Regarding the SQL standard, I think the best thing I can do is to refer you to http://en.wikipedia.org/wiki/SQL#Standardization Also, I made a mistake in my earlier mail: it is the SQL 2003 standard that standardized the OLAP operations T611 and T612, *not* the 1999 SQL standard. I will correct this in the Wiki pages. thanks, bryan
[jira] Commented: (DERBY-2950) BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with exception: java.sql.SQLException: Operand of LIKE predicate with type VARCHAR(128) and collation
[ https://issues.apache.org/jira/browse/DERBY-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513738 ] Kathey Marsden commented on DERBY-2950: --- In CollationTest.collatedSuite, you can just add the test and import BatchUpdateTest suite.addTest(BatchUpdateTest.suite()); > BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with > exception: java.sql.SQLException: Operand of LIKE predicate with type > VARCHAR(128) and collation UCS_BASIC is not compatable with LIKE pattern > operand with type CHAR(4) and collation > --- > > Key: DERBY-2950 > URL: https://issues.apache.org/jira/browse/DERBY-2950 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden > > BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with > exception: java.sql.SQLException: Operand of LIKE predicate with type > VARCHAR(128) and collation UCS_BASIC is not compatable with LIKE pattern > operand with type CHAR(4) and collation > Full trace below: > java.sql.SQLException: Operand of LIKE predicate with type VARCHAR(128) and > collation UCS_BASIC is not compatable with LIKE pattern operand with type > CHAR(4) and collation TERRITORY_BASED. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) > at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:202) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:391) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) > at > org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1572) > at > org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:585) > at > org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java:153) > at > org.apache.derbyTesting.functionTests.tests.jdbcapi.BatchUpdateTest.testMinimalDDLInBatch(BatchUpdateTest.java:248) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:615) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > or
[jira] Created: (DERBY-2952) create table from values clause causes error: ERROR 42ZA3: The table will have collation type UCS_BASIC which is different than the collation of the schema TERRITORY_BASE
create table from values clause causes error: ERROR 42ZA3: The table will have collation type UCS_BASIC which is different than the collation of the schema TERRITORY_BASED Key: DERBY-2952 URL: https://issues.apache.org/jira/browse/DERBY-2952 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 11.0.0.0 Reporter: Kathey Marsden To reproduce: ij> connect 'jdbc:derby:nordb;territory=no_NO;collation=TERRITORY_BASED;create=true'; ij> create table t3 (x,y) as values (1,'name') with no data; ERROR 42ZA3: The table will have collation type UCS_BASIC which is different than the collation of the schema TERRITORY_ BASED hence this operation is not supported . java.sql.SQLException: The table will have collation type UCS_BASIC which is different than the collation of the schema TERRITORY_BASED hence this operation is not supported . at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:202) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:391) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1572) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:585) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:528) at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:330) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:522) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:364) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:262) at org.apache.derby.impl.tools.ij.Main.go(Main.java:215) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181) at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:56) at org.apache.derby.tools.ij.main(ij.java:71) Caused by: ERROR 42ZA3: The table will have collation type UCS_BASIC which is different than the collation of the schema TERRITORY_BASED hence this operation is not supported . at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301) at org.apache.derby.impl.sql.compile.CreateTableNode.bindStatement(CreateTableNode.java:340) at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:314) at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConne ctionContext.java:753) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:579) ... 9 more This can also be seen in the test CreateTableFromQueryTest.testCreateTableFromValues -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2952) create table from values clause causes error: ERROR 42ZA3: The table will have collation type UCS_BASIC which is different than the collation of the schema TERRITORY_BASE
[ https://issues.apache.org/jira/browse/DERBY-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2952: -- Affects Version/s: (was: 11.0.0.0) 10.4.0.0 > create table from values clause causes error: ERROR 42ZA3: The table will > have collation type UCS_BASIC which is different than the collation of the > schema TERRITORY_BASED > > > Key: DERBY-2952 > URL: https://issues.apache.org/jira/browse/DERBY-2952 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden > > To reproduce: > ij> connect > 'jdbc:derby:nordb;territory=no_NO;collation=TERRITORY_BASED;create=true'; > ij> create table t3 (x,y) as values (1,'name') with no data; > ERROR 42ZA3: The table will have collation type UCS_BASIC which is different > than the collation of the schema TERRITORY_ > BASED hence this operation is not supported . > java.sql.SQLException: The table will have collation type UCS_BASIC which is > different than the collation of the schema > TERRITORY_BASED hence this operation is not supported . > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) > at > org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:202) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:391) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) > at > org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1572) > at > org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:585) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:528) > at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:330) > at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:522) > at > org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:364) > at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:262) > at org.apache.derby.impl.tools.ij.Main.go(Main.java:215) > at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181) > at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:56) > at org.apache.derby.tools.ij.main(ij.java:71) > Caused by: ERROR 42ZA3: The table will have collation type UCS_BASIC which is > different than the collation of the schema > TERRITORY_BASED hence this operation is not supported . > at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301) > at > org.apache.derby.impl.sql.compile.CreateTableNode.bindStatement(CreateTableNode.java:340) > at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:314) > at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88) > at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConne > ctionContext.java:753) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:579) > ... 9 more > This can also be seen in the test > CreateTableFromQueryTest.testCreateTableFromValues -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2941) With 10.2, Closing a resultset after retrieving a large > 32665 bytes value with Network Server does not release locks
[ https://issues.apache.org/jira/browse/DERBY-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513748 ] Myrna van Lunteren commented on DERBY-2941: --- I know you checked in the test to 10.3 branch, but I'm wondering if this issue should be marked fixed for 10.3.1.2? > With 10.2, Closing a resultset after retrieving a large > 32665 bytes value > with Network Server does not release locks > -- > > Key: DERBY-2941 > URL: https://issues.apache.org/jira/browse/DERBY-2941 > Project: Derby > Issue Type: Sub-task > Components: Network Server >Affects Versions: 10.2.2.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden > Fix For: 10.2.2.1, 10.3.1.2, 10.4.0.0 > > Attachments: DERBY-2941_diff.txt > > > Making a subtask for the 10.2 fix for this issue as the fix for 10.3 will be > different. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DERBY-2941) With 10.2, Closing a resultset after retrieving a large > 32665 bytes value with Network Server does not release locks
[ https://issues.apache.org/jira/browse/DERBY-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513748 ] Myrna van Lunteren edited comment on DERBY-2941 at 7/18/07 4:16 PM: I know you checked in the test to 10.3 branch, but I'm doubting that this issue should be marked fixed for 10.3.1.2? was: I know you checked in the test to 10.3 branch, but I'm wondering if this issue should be marked fixed for 10.3.1.2? > With 10.2, Closing a resultset after retrieving a large > 32665 bytes value > with Network Server does not release locks > -- > > Key: DERBY-2941 > URL: https://issues.apache.org/jira/browse/DERBY-2941 > Project: Derby > Issue Type: Sub-task > Components: Network Server >Affects Versions: 10.2.2.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden > Fix For: 10.2.2.1, 10.3.1.2, 10.4.0.0 > > Attachments: DERBY-2941_diff.txt > > > Making a subtask for the 10.2 fix for this issue as the fix for 10.3 will be > different. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2941) With 10.2, Closing a resultset after retrieving a large > 32665 bytes value with Network Server does not release locks
[ https://issues.apache.org/jira/browse/DERBY-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513751 ] Kathey Marsden commented on DERBY-2941: --- I checked the fix into the 10.3 branch as well, so hopefully the fix version is ok. It only fixes 10.2 client with 10.3. It does not fix 2892 10.3 client with 10.3. > With 10.2, Closing a resultset after retrieving a large > 32665 bytes value > with Network Server does not release locks > -- > > Key: DERBY-2941 > URL: https://issues.apache.org/jira/browse/DERBY-2941 > Project: Derby > Issue Type: Sub-task > Components: Network Server >Affects Versions: 10.2.2.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden > Fix For: 10.2.2.1, 10.3.1.2, 10.4.0.0 > > Attachments: DERBY-2941_diff.txt > > > Making a subtask for the 10.2 fix for this issue as the fix for 10.3 will be > different. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2942) Convert jdbcapi/statementJdbc30.java to JUnit
[ https://issues.apache.org/jira/browse/DERBY-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513753 ] Kathey Marsden commented on DERBY-2942: --- Hi Ramin, Thanks for the patch. A few minor comments: There are a few places where it says * * DERBY-2943 -- execute() and executeUpdate() return different * SQLState in embedded and network client * * Disabling Network Client */ if (!usingDerbyNetClient()) I think it would be better to test with network client but just use the usingDerbyClient() to check for a different exception. - The connection you get with getConnection in CleanDatabaseSetup is never used so can be removed. - There is no longer a need to close the statements created with createStatement() they are now cleaned up automatically. > Convert jdbcapi/statementJdbc30.java to JUnit > - > > Key: DERBY-2942 > URL: https://issues.apache.org/jira/browse/DERBY-2942 > Project: Derby > Issue Type: Task > Components: Test >Reporter: Ramin Moazeni >Assignee: Ramin Moazeni > Attachments: DERBY-2942v0.diff, DERBY-2942v0.stat > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: DERBY-581 and OLAP operations
Bryan Pendleton wrote: In the context of https://issues.apache.org/jira/browse/DERBY-581 I've been studying the SQL-99 standard's specification of OLAP operations: - Feature T611 specifies "Elementary OLAP operations" - Feature T612 specifies "Advanced OLAP operations" I'm interested in exploring an implementation of these features, and to start with I'd like to get the community's reaction: - Are these features that we're interested in seeing added to Derby? If one person wants to scratch that itch then that's all that's required. Go for it! :-) - Are there others in the community who are interested in working on these features? - How could we approach this incrementally, building enough functionality to be useful, arriving at a complete implementation in pieces over time? For example, would it be reasonable to build a subset of the T611 features at first, and then expand that functionality over time? Would it be reasonable to add new SQL syntax support, but have it work only in a subset of cases, and then expand the execution functionality over time to address more usages? Sounds good, progress, not perfection. Just try to avoid committing changes that result in working behaviour that might change in the future, i.e. a subset of working functionality is a great way to start. I was thinking that I might get started by trying to build one or more Wiki pages that describe some of the materials that might go into an implementation: - background information about the features and the concepts behind them - notes about the current Derby implementation, and about possible ways to extend the implementation in this area - ideas for how to subdivide and stage the implementation, in order to enable us to start talking about actual code. I would encourage extending Derby in ways that enhance the code clarity. For example, code might be cleaner by creating a new QueryTreeNode for any new grouping functionality rather than more 'if' statements or other complex logic in an existing GroupByNode. Or even cleaning up existing nodes to allow sharing between various related nodes. E.g. move common code from existing GroupByNode into an abstract node, and then have multiple nodes that handle grouping operations extend from that. Does this seem like a reasonable approach? +1 Dan.
[jira] Updated: (DERBY-2656) Run suites.All against a collated database
[ https://issues.apache.org/jira/browse/DERBY-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2656: -- Attachment: FullCollation.out Here are the results of running lang, jdbcapi and store suites on a collated database (running the test org.apache.derbyTesting.functionTests.tests.lang.FullCollationTests. I am investigating the failures and have started creating some bugs but thought I would post the full results in case anyone is interested. Kathey > Run suites.All against a collated database > -- > > Key: DERBY-2656 > URL: https://issues.apache.org/jira/browse/DERBY-2656 > Project: Derby > Issue Type: Task > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Fix For: 10.3.1.2 > > Attachments: DERBY-2656_diff.txt, FullCollation.out > > > It would be good to leverage the existing tests to exercise the collation > code. Investigate running all the tests against a collated database. > Kathey -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Regression Test Report - tinderbox_trunk16 557398 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 557398/2007-07-18 23:12:35 CEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 4298294 089.35% derbyall 086058605 0 2077.80% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-557398.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/557398_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/557398.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Updated: (DERBY-2656) Run suites.All against a collated database
[ https://issues.apache.org/jira/browse/DERBY-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2656: -- Attachment: (was: FullCollation.out) > Run suites.All against a collated database > -- > > Key: DERBY-2656 > URL: https://issues.apache.org/jira/browse/DERBY-2656 > Project: Derby > Issue Type: Task > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Fix For: 10.3.1.2 > > Attachments: DERBY-2656_diff.txt > > > It would be good to leverage the existing tests to exercise the collation > code. Investigate running all the tests against a collated database. > Kathey -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2656) Run suites.All against a collated database
[ https://issues.apache.org/jira/browse/DERBY-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513790 ] Kathey Marsden commented on DERBY-2656: --- I deleted FullCollation.out. There seems to be a problem with the run. > Run suites.All against a collated database > -- > > Key: DERBY-2656 > URL: https://issues.apache.org/jira/browse/DERBY-2656 > Project: Derby > Issue Type: Task > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Fix For: 10.3.1.2 > > Attachments: DERBY-2656_diff.txt > > > It would be good to leverage the existing tests to exercise the collation > code. Investigate running all the tests against a collated database. > Kathey -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: again, another 10.3.1. release candidate?
Myrna van Lunteren wrote: Hi, There was a discussion ensuing from DERBY-2896, which I think should be a general discussion item, following mamta's check-in for a fix for that critical issue. Knut Anders Wrote: >The changes in metadata.properties will not be picked up when you upgrade from 10.3.1.x to 10.3.2.x. Kathey replied: This filed as DERBY-1107 and I think is a good reason to have a new release candidate. I think other critical issues such as DERBY-2437 and the regression DERBY-2892 might be worth waiting for too if they can be fixed in short order. I wouldn't veto a release at this point but would probably vote -0. It seems to me that even though Kathey doesn't want to hold up the release, she really doesn't want a release without this fix. Which to me sounds like a new release candidate, which, as we've got a vote outstanding, means holding up the release. :-) But Kathey's email poses some options 1. I can do a fairly quick turn-around and make another release candidate after Mamta backports the fix to 10.3. If I can build the files tonight or tomorrow morning early, I can test, and call a vote around noon, that would give us until July 26th noon (PDT) and I could maybe still close the vote and hope that the maven work and web page work can be finished on that day, or leave it to Rick to do that part once he's back the week after. 2. We can wait until someone fixes DERBY-2892 for 10.3. I have not heard anything positive, nor a time frame for such a fix. If a fix happens before the 26th, I can generate new build files and open the voting, but someone else (Rick when he's back form vacation/conference?) will have to finish up the work for this release. 3. We can wait even further until other critical issues such as DERBY-2437 are fixed. I want to point out, that no has volunteered to own that one at this point, so we might be waiting indefinitely. I can, as I have suggested before, pick up the release work in September, and we can see how far the fixes are then. Or someone else can volunteer. Kathey, please be explicit, which 'other' issues except DERBY-2437 do you think are necessary to receive a fix? Well, since DERBY-2905 is a regression, I would love to see that one fixed, but I wouldn't call it necessary. I would like to see the analysis of DERBY-2656 complete. I can finish that by Monday. Ramin is I think close to a patch for DERBY-2925 which would fix DERBY-2437, but I am not sure how strongly Dag feels about that being the wrong solution. It has the advantage of being a solution. DERBY-1107 is I think not an easy bug to fix, so I think we should have a release candidate for DERBY-2896 to avoid having to fix it. That is the primary issue. So my vote would be to plan to make a new release candidate on Monday and hopefully we will be able to make a dent in some of these issues. People can continue banging away on 10.3 and see if we can pop more issues. Perhaps we'll even get more bugs fixed. Kathey
[jira] Updated: (DERBY-2656) Run suites.All against a collated database
[ https://issues.apache.org/jira/browse/DERBY-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2656: -- Attachment: FullCollationTests_out.txt Attaching new test output. There was a problem with the previous run. Kathey > Run suites.All against a collated database > -- > > Key: DERBY-2656 > URL: https://issues.apache.org/jira/browse/DERBY-2656 > Project: Derby > Issue Type: Task > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Kathey Marsden >Assignee: Kathey Marsden >Priority: Minor > Fix For: 10.3.1.2 > > Attachments: DERBY-2656_diff.txt, FullCollationTests_out.txt > > > It would be good to leverage the existing tests to exercise the collation > code. Investigate running all the tests against a collated database. > Kathey -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2950) BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with exception: java.sql.SQLException: Operand of LIKE predicate with type VARCHAR(128) and collation
[ https://issues.apache.org/jira/browse/DERBY-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513816 ] Mamta A. Satoor commented on DERBY-2950: I do not think this is a bug. The exception is being thrown for following in BatchUpdateTest.testMinimalDDLInBatch when the current schema is a user schema ResultSet rs = stmt.executeQuery( "select count(*) from SYS.SYSTABLES where tablename like 'DDL%'"); Because current schema is user schema, the character string literal 'DDL%' gets a collation of territory based. But the other operand of LIKE which is tablename has collation of UCS_BASIC. This mismatch in collation type causes the exception. The problem can be fixed in one of the 2 ways 1)by using a CAST on tablename ResultSet rs = stmt.executeQuery( "select count(*) from SYS.SYSTABLES where CAST(tablename as CHAR(30)) like 'DDL%'"); 2)by running the query in SYS schema rather than user schema. > BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with > exception: java.sql.SQLException: Operand of LIKE predicate with type > VARCHAR(128) and collation UCS_BASIC is not compatable with LIKE pattern > operand with type CHAR(4) and collation > --- > > Key: DERBY-2950 > URL: https://issues.apache.org/jira/browse/DERBY-2950 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden > > BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with > exception: java.sql.SQLException: Operand of LIKE predicate with type > VARCHAR(128) and collation UCS_BASIC is not compatable with LIKE pattern > operand with type CHAR(4) and collation > Full trace below: > java.sql.SQLException: Operand of LIKE predicate with type VARCHAR(128) and > collation UCS_BASIC is not compatable with LIKE pattern operand with type > CHAR(4) and collation TERRITORY_BASED. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) > at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:202) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:391) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) > at > org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1572) > at > org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:585) > at > org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java:153) > at > org.apache.derbyTesting.functionTests.tests.jdbcapi.BatchUpdateTest.testMinimalDDLInBatch(BatchUpdateTest.java:248) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:615) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetu
[jira] Assigned: (DERBY-2950) BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with exception: java.sql.SQLException: Operand of LIKE predicate with type VARCHAR(128) and collation
[ https://issues.apache.org/jira/browse/DERBY-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor reassigned DERBY-2950: -- Assignee: Mamta A. Satoor > BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with > exception: java.sql.SQLException: Operand of LIKE predicate with type > VARCHAR(128) and collation UCS_BASIC is not compatable with LIKE pattern > operand with type CHAR(4) and collation > --- > > Key: DERBY-2950 > URL: https://issues.apache.org/jira/browse/DERBY-2950 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.4.0.0 >Reporter: Kathey Marsden >Assignee: Mamta A. Satoor > > BatchUpdateTest.testMinimalDDLInBatch Fails when run with collation with > exception: java.sql.SQLException: Operand of LIKE predicate with type > VARCHAR(128) and collation UCS_BASIC is not compatable with LIKE pattern > operand with type CHAR(4) and collation > Full trace below: > java.sql.SQLException: Operand of LIKE predicate with type VARCHAR(128) and > collation UCS_BASIC is not compatable with LIKE pattern operand with type > CHAR(4) and collation TERRITORY_BASED. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) > at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:202) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:391) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) > at > org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1572) > at > org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:585) > at > org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java:153) > at > org.apache.derbyTesting.functionTests.tests.jdbcapi.BatchUpdateTest.testMinimalDDLInBatch(BatchUpdateTest.java:248) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:615) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at ju
Regression Test Report - tinderbox_trunk16 557447 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 557447/2007-07-19 03:52:41 CEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 4298294 089.09% derbyall 086058605 0 1986.72% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-557447.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/557447_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/557447.txt ( All results in http://dbtg.thresher.com/derby/test/ )
