[jira] Commented: (DERBY-1764) Rewrite stress.multi as a JUnit test
[ https://issues.apache.org/jira/browse/DERBY-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12610898#action_12610898 ] Knut Anders Hatlen commented on DERBY-1764: --- 2) Need to add functionality so that if threads hang and cannot finish on their own, we dump the stack traces and interrupt the threads. I think this is important as when we have had failures in this test in the past, we have seen the threads hang. Perhaps it better to let it hang? One can always get the stack traces with kill -QUIT or jstack when the hang happens, and one can also attach a debugger to the process to see what's going on. Interrupting the test may prevent cleanup code from being executed or leave the engine in a bad state, which can cause subsequent errors and make the problem harder to debug. Rewrite stress.multi as a JUnit test Key: DERBY-1764 URL: https://issues.apache.org/jira/browse/DERBY-1764 Project: Derby Issue Type: Test Components: Test Reporter: Knut Anders Hatlen Assignee: Erlend Birkenes Attachments: derby-1764-derby.log, DERBY-1764-Review.diff, DERBY-1764-V1.diff, DERBY-1764-V2.diff Currently, stress.multi consists of a number of sql scripts that are run in ij. It often fails with cryptic error messages, and since it uses ij, there is often no stack trace. It would be very useful to rewrite the test in JUnit so that we can get better error messages and stack traces when it fails. -- 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 674384 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 674384/2008-07-07 04:42:27 CEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 022 0 115.78% org.apache.derbyTesting.functionTests.tests.demo._Suite F:1,E:01019510194 0 1672.99% org.apache.derbyTesting.functionTests.suites.All 0261261 0 110.71% derbyall 022 0 168.97% org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.CompatibilityCombinations 088 0 108.50% org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationSuite Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-674384.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/674384_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/674384.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Created: (DERBY-3761) Convert org.apache.derbyTesting.functionTests.tests.lang.connect.sql to junit. It it a part of 2008 GSOC.
Convert org.apache.derbyTesting.functionTests.tests.lang.connect.sql to junit. It it a part of 2008 GSOC. --- Key: DERBY-3761 URL: https://issues.apache.org/jira/browse/DERBY-3761 Project: Derby Issue Type: Test Reporter: Junjie Peng -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3762) Convert org.apache.derbyTesting.functionTests.tests.lang.arithmetic.sql to junit.
Convert org.apache.derbyTesting.functionTests.tests.lang.arithmetic.sql to junit. Key: DERBY-3762 URL: https://issues.apache.org/jira/browse/DERBY-3762 Project: Derby Issue Type: Test Environment: windows xp, sp2. Reporter: Junjie Peng Assignee: Junjie Peng Convert org.apache.derbyTesting.functionTests.tests.lang.arithmetic.sql to junit. It it a part of 2008 GSOC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1764) Rewrite stress.multi as a JUnit test
[ https://issues.apache.org/jira/browse/DERBY-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-1764: --- Attachment: derby-1764-3a-whitespace_changes.diff 'derby-1764-3a-whitespace_changes.diff' changes a class name in one of the license headers, removes tabs and trailing spaces and corrects the indentation level in a few places. No functional changes. Committed to trunk with revision 674412. Rewrite stress.multi as a JUnit test Key: DERBY-1764 URL: https://issues.apache.org/jira/browse/DERBY-1764 Project: Derby Issue Type: Test Components: Test Reporter: Knut Anders Hatlen Assignee: Erlend Birkenes Attachments: derby-1764-3a-whitespace_changes.diff, derby-1764-derby.log, DERBY-1764-Review.diff, DERBY-1764-V1.diff, DERBY-1764-V2.diff Currently, stress.multi consists of a number of sql scripts that are run in ij. It often fails with cryptic error messages, and since it uses ij, there is often no stack trace. It would be very useful to rewrite the test in JUnit so that we can get better error messages and stack traces when it fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3762) Convert org.apache.derbyTesting.functionTests.tests.lang.arithmetic.sql to junit.
[ https://issues.apache.org/jira/browse/DERBY-3762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Junjie Peng updated DERBY-3762: --- Attachment: derby-3762-1-stat.txt derby-3762-1-patch.txt Please check the patch! Thank you! Convert org.apache.derbyTesting.functionTests.tests.lang.arithmetic.sql to junit. Key: DERBY-3762 URL: https://issues.apache.org/jira/browse/DERBY-3762 Project: Derby Issue Type: Test Environment: windows xp, sp2. Reporter: Junjie Peng Assignee: Junjie Peng Attachments: derby-3762-1-patch.txt, derby-3762-1-stat.txt Original Estimate: 120h Remaining Estimate: 120h Convert org.apache.derbyTesting.functionTests.tests.lang.arithmetic.sql to junit. It it a part of 2008 GSOC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3761) Convert org.apache.derbyTesting.functionTests.tests.lang.connect.sql to junit. It it a part of 2008 GSOC.
[ https://issues.apache.org/jira/browse/DERBY-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12610908#action_12610908 ] Junjie Peng commented on DERBY-3761: It's a invalid issue, because of wrong click. It should be deleted! I'm sorry! Convert org.apache.derbyTesting.functionTests.tests.lang.connect.sql to junit. It it a part of 2008 GSOC. --- Key: DERBY-3761 URL: https://issues.apache.org/jira/browse/DERBY-3761 Project: Derby Issue Type: Test Reporter: Junjie Peng -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3761) Convert org.apache.derbyTesting.functionTests.tests.lang.connect.sql to junit. It it a part of 2008 GSOC.
[ https://issues.apache.org/jira/browse/DERBY-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Junjie Peng closed DERBY-3761. -- Resolution: Fixed Convert org.apache.derbyTesting.functionTests.tests.lang.connect.sql to junit. It it a part of 2008 GSOC. --- Key: DERBY-3761 URL: https://issues.apache.org/jira/browse/DERBY-3761 Project: Derby Issue Type: Test Reporter: Junjie Peng -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3327) SQL roles: Implement authorization stack (and SQL session context to hold it)
[ https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik closed DERBY-3327. Resolution: Fixed Derby Info: [Existing Application Impact, Release Note Needed] (was: [Release Note Needed, Existing Application Impact]) SQL roles: Implement authorization stack (and SQL session context to hold it) - Key: DERBY-3327 URL: https://issues.apache.org/jira/browse/DERBY-3327 Project: Derby Issue Type: New Feature Components: Security, SQL Reporter: Dag H. Wanvik Assignee: Dag H. Wanvik Fix For: 10.5.0.0 Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff, DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat, DERBY-3327-4-full-b.diff, DERBY-3327-4-full-b.stat, DERBY-3327-4-full-c.diff, DERBY-3327-4-full-c.stat, DERBY-3327-4-full-d.diff, DERBY-3327-4-full-d.stat, DERBY-3327-4-full-e-10_4.diff, DERBY-3327-4-full-e-10_4.stat, DERBY-3327-4-full-e.diff, DERBY-3327-4-full-e.stat, DERBY-3327-4-full.diff, DERBY-3327-4-full.stat, derby-3327-5a-extracted_initial_schema_patch.diff, DERBY-3327-6.diff, DERBY-3327-6.stat, releaseNote.html The current LanguageConnectionContext keeps the user authorization identifier for an SQL session. The lcc is shared context also for nested connections (opened from stored procedures). So far, for roles, the current role has been stored in the lcc also. However, SQL requires that authorization identifers be pushed on a authorization stack when calling a stored procedure, cf. SQL 2003, vol 2, section 4.34.1.1 and 4.27.3 and 10.4 GR 5h and i. This allows a caller to keep its current role after a call even if changed by the stored procedure. This issue will implement the current role name part (cell) of the authorization stack. The authorization stack will be implemented as part of the SQL session context. The patch will also implement the pushing of the current unqualified schema name part of the SQL session context, cf. 10.4 GR 5a (DERBY-1331). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3743) Revoking EXECUTE privilege on a function if used in a CHECK constraint: implementation problem
[ https://issues.apache.org/jira/browse/DERBY-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12610913#action_12610913 ] Dag H. Wanvik commented on DERBY-3743: -- I should add that derby-3743 also adds the test case from the patch derby-3743-show-constraint-invalidate-actions to make sure the implementation change doesn't break the behavior. I will commit this soon if no objections. Revoking EXECUTE privilege on a function if used in a CHECK constraint: implementation problem --- Key: DERBY-3743 URL: https://issues.apache.org/jira/browse/DERBY-3743 Project: Derby Issue Type: Improvement Components: Security, SQL Affects Versions: 10.5.0.0 Reporter: Dag H. Wanvik Assignee: Dag H. Wanvik Attachments: derby-3743-show-constraint-invalidate-actions.diff, derby-3743-show-constraint-invalidate-actions.stat, derby-3743.diff, derby-3743.stat The docs say that REVOKE EXECUTE ... RESTRICT should fail if there is a dependent constraint: The RESTRICT clause specifies that the EXECUTE privilege cannot be revoked if the specified routine is used in a view, trigger, or constraint, and the privilege is being revoked from the owner of the view, trigger, or constraint. Revoking the privilege will be correctly restricted, but possibly for the wrong reason. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3736) Revoking a column level privilege from a user, a prepared statement relying on that privilege can still be executed
[ https://issues.apache.org/jira/browse/DERBY-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-3736: - Attachment: derby-3736b.stat derby-3736b.diff Updating a new version, derby-3736b which replaces the first version. This adds the comment Rick asked for plus fixes some whitespace issues. I will commit this soon if no objects arise. Revoking a column level privilege from a user, a prepared statement relying on that privilege can still be executed Key: DERBY-3736 URL: https://issues.apache.org/jira/browse/DERBY-3736 Project: Derby Issue Type: Bug Components: Security, SQL Affects Versions: 10.3.1.4, 10.3.2.1, 10.3.3.0, 10.4.1.3 Reporter: Dag H. Wanvik Assignee: Dag H. Wanvik Attachments: column-level.sql, derby-3736.diff, derby-3736.stat, derby-3736b.diff, derby-3736b.stat, GrantRevokeDDLTest.diff, table-level.sql When a table level SELECT privilege is revoked, a dependent prepared statement is invalidated and can no longer be executed, but in the case of a column level privilege SELECT privilege, the dependent prepared statement can still be executed. This works as expected in 10.2, but does not work in all 10.3 and 10.4 releases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3319) Logical connections do not check if a transaction is active on close
[ https://issues.apache.org/jira/browse/DERBY-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12610917#action_12610917 ] Knut Anders Hatlen commented on DERBY-3319: --- Currently, plain connections (from DriverManager) throw an exception on close if they have uncommitted operations and they have auto-commit off. I think connections that come from data sources should behave the same way, but if the connection is associated with an XA transaction, I think it should not throw an exception because a) the connection object doesn't control commit/rollback. Even if the connection is closed, the global transaction can still be committed or rolled back with the XAResource. I think the rationale for disallowing close on plain connections when the transaction is active, is that there's no way to end the transaction after the connection is closed. Since this is not the case for XA transactions, there's no need to throw the exception. b) there are regression tests that depend on the ability to close a connection before ending the associated XA transaction (sequences like XAResource.start() ... XAConnection.getConnection() ... Connection.close() ... XAConnection.getConnection() ... Connection.close() ... XAResource.end()) so keeping the current behaviour for these connections sounds safer Unless there are objections to this approach, I'll post a patch which implements this new behaviour. Logical connections do not check if a transaction is active on close Key: DERBY-3319 URL: https://issues.apache.org/jira/browse/DERBY-3319 Project: Derby Issue Type: Bug Components: JDBC, Network Client Affects Versions: 10.3.2.1, 10.4.1.3, 10.5.0.0 Environment: Embedded driver and client driver. Reporter: Kristian Waagan Assignee: Knut Anders Hatlen Attachments: LogicalConnectionCloseActiveTransactionBug.java If you call close on a logical connection, for instance as obtained through a PooledConnection, it does not check if there is an active transaction. The close of the logical connection is allowed, and even the close of the parent PooledConnection is allowed in the client driver. This can/will cause resources to be left on the server, and later operations might fail (typically with lock timeouts because the closed transaction is still holding locks). I do not know if gc will solve this eventually, but I would say the current behavior of the client driver is wrong in any case. There is difference in the behavior between the embedded and the client driver, and there also seems to be a bug in the embedded driver. The analysis above is a bit sketchy, so it might be required to look into the issue a bit more... I will attach a repro (JDBC usage should be verified as well, is it legal / as intended?) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3751) Convert case.sql to junit
[ https://issues.apache.org/jira/browse/DERBY-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan resolved DERBY-3751. Resolution: Fixed Fix Version/s: 10.5.0.0 Derby Info: (was: [Patch Available]) Thanks for the updated patch Junjie. I committed 'derby-3751-2-patch.txt' to trunk with revision 674451. As the reporter of the issue, feel free to close it when you have verified the fix/commit. Convert case.sql to junit - Key: DERBY-3751 URL: https://issues.apache.org/jira/browse/DERBY-3751 Project: Derby Issue Type: Test Components: Test Environment: Windows Xp, sp2. Reporter: Junjie Peng Assignee: Junjie Peng Fix For: 10.5.0.0 Attachments: derby-3751-1-patch.txt, derby-3751-1-stat.txt, derby-3751-2-patch.txt, derby-3751-2-stat.txt, derby-3751-patch.txt Original Estimate: 72h Remaining Estimate: 72h In the package org.apache.derbyTesting.functionTests.tests.lang, we have both CaseExpressionTest.java and case.sql, which are both about case. Now, I would like to convert case.sql to junit, and I will add new test cases into CaseExpressionTest.java ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3313) JDBC client driver statement cache
[ https://issues.apache.org/jira/browse/DERBY-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3313: --- Attachment: package.html 'package.html' is the first revision of a simple package level description of the JDBC statement cache. It would be nice if someone could read through it and comment on two things: 1) Language errors 2) Missing or poor information about the cache. For instance, more information regarding the implementation could be added. JDBC client driver statement cache -- Key: DERBY-3313 URL: https://issues.apache.org/jira/browse/DERBY-3313 Project: Derby Issue Type: New Feature Components: JDBC, Network Client Affects Versions: 10.4.1.3 Reporter: Kristian Waagan Assignee: Kristian Waagan Fix For: 10.4.1.3 Attachments: bank_transaction_stmtcache_16c.png, derby-3313-1a-early_prototype.diff, derby-3313-1a-early_prototype.stat, JDBCClientStatementCacheOverview.txt, JDBCClientStatementCacheOverview.txt, package.html A statement cache in the JDBC client driver will help increase performance in certain scenarios, for instance some multi-tier systems using connection pooling. Please consult the comments and documents attached to this issue for more information. -- 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 674412 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 674412/2008-07-07 09:52:13 CEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 022 0 121.05% org.apache.derbyTesting.functionTests.tests.demo._Suite 01019510195 0 1687.41% org.apache.derbyTesting.functionTests.suites.All 0261261 0 110.20% derbyall 022 0 167.63% org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.CompatibilityCombinations F:1,E:087 0 107.16% org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationSuite Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-674412.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/674412_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/674412.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Assigned: (DERBY-1944) jdbcapi/parameterMapping.java test does not execute test for setObject(Blob/Clob) in DerbyNetClient
[ https://issues.apache.org/jira/browse/DERBY-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan reassigned DERBY-1944: -- Assignee: Kristian Waagan jdbcapi/parameterMapping.java test does not execute test for setObject(Blob/Clob) in DerbyNetClient Key: DERBY-1944 URL: https://issues.apache.org/jira/browse/DERBY-1944 Project: Derby Issue Type: Test Components: Network Client, Test Reporter: Tomohito Nakayama Assignee: Kristian Waagan The jdbcapi/parameterMapping.java tests type compatibility and it does not test setObject(Blob/Clob) in DerbyNetClient. 5) at http://issues.apache.org/jira/browse/DERBY-1610#action_12430700 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1944) jdbcapi/ParameterMappingTest.java test does not execute test for setObject(Blob/Clob) in DerbyNetClient
[ https://issues.apache.org/jira/browse/DERBY-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-1944: --- Affects Version/s: 10.5.0.0 Summary: jdbcapi/ParameterMappingTest.java test does not execute test for setObject(Blob/Clob) in DerbyNetClient (was: jdbcapi/parameterMapping.java test does not execute test for setObject(Blob/Clob) in DerbyNetClient) Although the test has been converted to a JUnit test, the reported issue still remains. I changed the name of the test in the summary. jdbcapi/ParameterMappingTest.java test does not execute test for setObject(Blob/Clob) in DerbyNetClient Key: DERBY-1944 URL: https://issues.apache.org/jira/browse/DERBY-1944 Project: Derby Issue Type: Test Components: Network Client, Test Affects Versions: 10.5.0.0 Reporter: Tomohito Nakayama Assignee: Kristian Waagan The jdbcapi/parameterMapping.java tests type compatibility and it does not test setObject(Blob/Clob) in DerbyNetClient. 5) at http://issues.apache.org/jira/browse/DERBY-1610#action_12430700 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1944) jdbcapi/ParameterMappingTest.java test does not execute test for setObject(Blob/Clob) in DerbyNetClient
[ https://issues.apache.org/jira/browse/DERBY-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-1944: --- Derby Info: [Patch Available] jdbcapi/ParameterMappingTest.java test does not execute test for setObject(Blob/Clob) in DerbyNetClient Key: DERBY-1944 URL: https://issues.apache.org/jira/browse/DERBY-1944 Project: Derby Issue Type: Test Components: Network Client, Test Affects Versions: 10.5.0.0 Reporter: Tomohito Nakayama Assignee: Kristian Waagan Attachments: derby-1944-1a.diff The jdbcapi/parameterMapping.java tests type compatibility and it does not test setObject(Blob/Clob) in DerbyNetClient. 5) at http://issues.apache.org/jira/browse/DERBY-1610#action_12430700 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1944) jdbcapi/ParameterMappingTest.java test does not execute test for setObject(Blob/Clob) in DerbyNetClient
[ https://issues.apache.org/jira/browse/DERBY-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-1944: --- Attachment: derby-1944-1a.diff 'derby-1944-1a.diff' enables tests for Blob and Clob. Removes one if-block, adds two small comments and reindents two blocks of code. Patch ready for review. jdbcapi/ParameterMappingTest.java test does not execute test for setObject(Blob/Clob) in DerbyNetClient Key: DERBY-1944 URL: https://issues.apache.org/jira/browse/DERBY-1944 Project: Derby Issue Type: Test Components: Network Client, Test Affects Versions: 10.5.0.0 Reporter: Tomohito Nakayama Assignee: Kristian Waagan Attachments: derby-1944-1a.diff The jdbcapi/parameterMapping.java tests type compatibility and it does not test setObject(Blob/Clob) in DerbyNetClient. 5) at http://issues.apache.org/jira/browse/DERBY-1610#action_12430700 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3763) Rename BaseJDBCTestCase.usingDerbyNet
Rename BaseJDBCTestCase.usingDerbyNet - Key: DERBY-3763 URL: https://issues.apache.org/jira/browse/DERBY-3763 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.5.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Trivial The names of the methods 'usingDerbyNet' and 'usingDerbyNetClient' in BaseJDBCTestCase are confusing. I propose we change the one used to tell if we are using the DB2 client driver (JCC). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3763) Rename BaseJDBCTestCase.usingDerbyNet
[ https://issues.apache.org/jira/browse/DERBY-3763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3763: --- Attachment: derby-3763-1a-usingDB2Client.stat derby-3763-1a-usingDB2Client.diff 'derby-3763-1a-usingDB2Client.diff' renames BaseJDBCTestCase.usingDerbyNet to usingDB2Client. There might be better names, I'm open for suggestions! Patch ready for review. Rename BaseJDBCTestCase.usingDerbyNet - Key: DERBY-3763 URL: https://issues.apache.org/jira/browse/DERBY-3763 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.5.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Trivial Attachments: derby-3763-1a-usingDB2Client.diff, derby-3763-1a-usingDB2Client.stat The names of the methods 'usingDerbyNet' and 'usingDerbyNetClient' in BaseJDBCTestCase are confusing. I propose we change the one used to tell if we are using the DB2 client driver (JCC). -- 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 (16 issues) Subscriber: derby-dev Key Summary DERBY-3763 Rename BaseJDBCTestCase.usingDerbyNet https://issues.apache.org/jira/browse/DERBY-3763 DERBY-1944 jdbcapi/ParameterMappingTest.java test does not execute test for setObject(Blob/Clob) in DerbyNetClient https://issues.apache.org/jira/browse/DERBY-1944 DERBY-3736 Revoking a column level privilege from a user, a prepared statement relying on that privilege can still be executed https://issues.apache.org/jira/browse/DERBY-3736 DERBY-3743 Revoking EXECUTE privilege on a function if used in a CHECK constraint: implementation problem https://issues.apache.org/jira/browse/DERBY-3743 DERBY-3762 Convert org.apache.derbyTesting.functionTests.tests.lang.arithmetic.sql to junit. https://issues.apache.org/jira/browse/DERBY-3762 DERBY-3760 Convert org.apache.derbyTesting.functionTests.tests.lang.miscerrors.sql to junit. https://issues.apache.org/jira/browse/DERBY-3760 DERBY-3759 Convert org.apache.derbyTesting.functionTests.tests.lang.ungroupedAggregatesNegative.sql to junit. https://issues.apache.org/jira/browse/DERBY-3759 DERBY-3758 Convert org.apache.derbyTesting.functionTests.tests.lang.precedence.sql to junit https://issues.apache.org/jira/browse/DERBY-3758 DERBY-3706 NetworkServer console messages should print a time stamp https://issues.apache.org/jira/browse/DERBY-3706 DERBY-3755 ij's help text lacks the optional [HOLD | NOHOLD] syntax for GET CURSOR https://issues.apache.org/jira/browse/DERBY-3755 DERBY-3750 Convert org.apache.derbyTesting.functionTests.tests.lang.constant Expression.sql to junit https://issues.apache.org/jira/browse/DERBY-3750 DERBY-3754 Convert org.apache.derbyTesting.functionTests.tests.lang.connect.sql to junit https://issues.apache.org/jira/browse/DERBY-3754 DERBY-3652 Derby does not follow the SQL Standard when trying to map SQL routines to Java methods. https://issues.apache.org/jira/browse/DERBY-3652 DERBY-3738 Add more tests for legal/illegal commands in the different replication states https://issues.apache.org/jira/browse/DERBY-3738 DERBY-3579 The Developer's Guide incorrectly describes the behavior of transactions inside procedures and functions https://issues.apache.org/jira/browse/DERBY-3579 DERBY-3200 Developer's Guide: Add examples showing use of SQL authorization with user authentication https://issues.apache.org/jira/browse/DERBY-3200
Re: simpler api to the Derby store
Knut Anders Hatlen [EMAIL PROTECTED] writes: although the API could need to be cleaned up and made easier. If someone wants to do such a cleanup, I think it would be good because a) it may make Derby code that accesses the store simpler (easier to understand, more maintainable) b) it is easier for other projects to use Derby's store directly without needing to fork Derby's code base (which potentially increases Derby's user base and the chance of getting contributions back from those projects) If the API were cleaner/easier, it would also make it more palatable to produce other backends for Derby. We have had attempts to make main memory backends; I am not sure why these never made it into production, though, could a backend API complexity be one reason?
[jira] Created: (DERBY-3764) Union Query fail on Derby 10.4.1.3
Union Query fail on Derby 10.4.1.3 -- Key: DERBY-3764 URL: https://issues.apache.org/jira/browse/DERBY-3764 Project: Derby Issue Type: Bug Affects Versions: 10.4.1.3, 10.3.1.4 Environment: Windows XP SP2, NetBeans 6.1 (IDE), Pentium 2 Core 512 Ram, Java 1.6.0_05 Reporter: Heleno da Silva Alves Running a Query on Derby 10.4.1.3 and 10.3.1.4 I got this error message: Error code 0, SQL state XJ001: Java Exception: '4 = 4: java.lang.ArrayIndexOutOfBoundsException'. After throw this exception the database shutdown and lost the connection. I'm updating an application from a previous version of Derby (Bundle-Version: 10.0.201 From derby.jar Manifest) so this query works fine in version 10.0. The Query: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo The deby log entry: 2008-07-07 14:44:51.282 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.3.1.4 - (561794): instance c013800d-011a-fdfb-6fa4-3451d386 on database directory C:\PAD\database Database Class Loader started - derby.database.classpath='' 2008-07-07 14:46:40.506 GMT Thread[SQLExecution,1,system] (XID = 3441038), (SESSIONID = 0), (DATABASE = C:\PAD\database), (DRDAID = null), Cleanup action starting 2008-07-07 14:46:40.506 GMT Thread[SQLExecution,1,system] (XID = 3441038), (SESSIONID = 0), (DATABASE = C:\PAD\database), (DRDAID = null), Failed Statement is: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo java.lang.ArrayIndexOutOfBoundsException: 4 = 4 at java.util.Vector.elementAt(Vector.java:427) at org.apache.derby.impl.sql.compile.QueryTreeNodeVector.elementAt(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumnList.setUnionResultExpression(Unknown Source) at org.apache.derby.impl.sql.compile.SetOperatorNode.buildRCL(Unknown Source) at org.apache.derby.impl.sql.compile.SetOperatorNode.bindResultColumns(Unknown Source) at org.apache.derby.impl.sql.compile.CursorNode.bindStatement(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.netbeans.modules.db.sql.execute.SQLExecuteHelper.execute(SQLExecuteHelper.java:114) at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor.run(SQLEditorSupport.java:479) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986) Cleanup action completed -- 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 674308 - Sun DBTG
[Auto-generated mail] *Daily* 674308/2008-07-06 18:01:04 MEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin F:2,E:01017510173 0 1321.28% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 0261261 081.12% derbyall 022 0 241.36% compatibility 088 099.14% replicationSuite 022 0 .% demoSuite sles 01019510195 0 864.16% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 1261260 074.14% derbyall 022 0 176.60% compatibility 088 0 100.27% replicationSuite 022 0 .% demoSuite sol F:1,E:01019510194 0 1336.42% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 0261261 075.68% derbyall 022 0 162.33% compatibility 088 0 100.74% replicationSuite 022 0 .% demoSuite solN+1 01019510195 0 152.66% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 0261261 098.29% derbyall 022 0 158.43% compatibility 088 0 100.98% replicationSuite 022 0 .% demoSuite sparc 01019510195 0 388.38% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 1261260 066.13% derbyall 022 0 139.17% compatibility 088 0 102.90% replicationSuite 022 0 .% demoSuite vista 090179017 073.16% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 0261261 093.48% derbyall NA NA NANA compatibility 088 0 .% replicationSuite 022 0 .% demoSuite vista-64 F:1,E:190179015 0 108.48% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 0261261 098.12% derbyall NA NA NANA compatibility 088 0 .% replicationSuite 022 0 .% demoSuite w2003 090179017 0 139.08% suitesAll 01313 0 .% jdbcapiAutoLoad 01212 0 .% JDBCDriversAll 01313 0 .% JDBCDriversClient 01212 0 .% JDBCDriversEmbedded 0261261 092.44% derbyall NA NA NANA compatibility 088 0 .% replicationSuite 022 0 .% demoSuite Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-674308.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/674308_bySig.html *Jvm: 1.5* lin 0262262 079.06% derbyall 084438443 0 1109.31% suitesAll sles 0262262 069.77% derbyall 084438443 0 633.91% suitesAll sol 0262262 079.19% derbyall 084438443 0 921.08% suitesAll solN+1 0262262 088.90% derbyall 084438443 0 878.24% suitesAll sparc 0262262 066.91% derbyall 084438443 0 775.47% suitesAll vista 0262262 070.80% derbyall 072657265 0 441.17% suitesAll w2003 0262262 071.67% derbyall 072657265 0 283.96% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-674308.html Attempted failure analysis in
[jira] Commented: (DERBY-1944) jdbcapi/ParameterMappingTest.java test does not execute test for setObject(Blob/Clob) in DerbyNetClient
[ https://issues.apache.org/jira/browse/DERBY-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611212#action_12611212 ] Dag H. Wanvik commented on DERBY-1944: -- Patch looks good to me. I compiled and tested successfully with the patch. +1 Why it was originally excluded? jdbcapi/ParameterMappingTest.java test does not execute test for setObject(Blob/Clob) in DerbyNetClient Key: DERBY-1944 URL: https://issues.apache.org/jira/browse/DERBY-1944 Project: Derby Issue Type: Test Components: Network Client, Test Affects Versions: 10.5.0.0 Reporter: Tomohito Nakayama Assignee: Kristian Waagan Attachments: derby-1944-1a.diff The jdbcapi/parameterMapping.java tests type compatibility and it does not test setObject(Blob/Clob) in DerbyNetClient. 5) at http://issues.apache.org/jira/browse/DERBY-1610#action_12430700 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3764) Union Query fail on Derby 10.4.1.3
[ https://issues.apache.org/jira/browse/DERBY-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heleno da Silva Alves updated DERBY-3764: - Attachment: CONSTAS_REMESSA.sql To create the Test Table Union Query fail on Derby 10.4.1.3 -- Key: DERBY-3764 URL: https://issues.apache.org/jira/browse/DERBY-3764 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.4.1.3 Environment: Windows XP SP2, NetBeans 6.1 (IDE), Pentium 2 Core 512 Ram, Java 1.6.0_05 Reporter: Heleno da Silva Alves Attachments: CONSTAS_REMESSA.sql Running a Query on Derby 10.4.1.3 and 10.3.1.4 I got this error message: Error code 0, SQL state XJ001: Java Exception: '4 = 4: java.lang.ArrayIndexOutOfBoundsException'. After throw this exception the database shutdown and lost the connection. I'm updating an application from a previous version of Derby (Bundle-Version: 10.0.201 From derby.jar Manifest) so this query works fine in version 10.0. The Query: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo The deby log entry: 2008-07-07 14:44:51.282 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.3.1.4 - (561794): instance c013800d-011a-fdfb-6fa4-3451d386 on database directory C:\PAD\database Database Class Loader started - derby.database.classpath='' 2008-07-07 14:46:40.506 GMT Thread[SQLExecution,1,system] (XID = 3441038), (SESSIONID = 0), (DATABASE = C:\PAD\database), (DRDAID = null), Cleanup action starting 2008-07-07 14:46:40.506 GMT Thread[SQLExecution,1,system] (XID = 3441038), (SESSIONID = 0), (DATABASE = C:\PAD\database), (DRDAID = null), Failed Statement is: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo java.lang.ArrayIndexOutOfBoundsException: 4 = 4 at java.util.Vector.elementAt(Vector.java:427) at org.apache.derby.impl.sql.compile.QueryTreeNodeVector.elementAt(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumnList.setUnionResultExpression(Unknown Source) at org.apache.derby.impl.sql.compile.SetOperatorNode.buildRCL(Unknown Source) at org.apache.derby.impl.sql.compile.SetOperatorNode.bindResultColumns(Unknown Source) at org.apache.derby.impl.sql.compile.CursorNode.bindStatement(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.netbeans.modules.db.sql.execute.SQLExecuteHelper.execute(SQLExecuteHelper.java:114) at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor.run(SQLEditorSupport.java:479) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986) Cleanup action completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3764) Union Query fail on Derby 10.4.1.3
[ https://issues.apache.org/jira/browse/DERBY-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heleno da Silva Alves updated DERBY-3764: - Attachment: database_test.10.0.zip Derby 10.0 - Works Fine Union Query fail on Derby 10.4.1.3 -- Key: DERBY-3764 URL: https://issues.apache.org/jira/browse/DERBY-3764 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.4.1.3 Environment: Windows XP SP2, NetBeans 6.1 (IDE), Pentium 2 Core 512 Ram, Java 1.6.0_05 Reporter: Heleno da Silva Alves Attachments: CONSTAS_REMESSA.sql, database_test.10.0.zip Running a Query on Derby 10.4.1.3 and 10.3.1.4 I got this error message: Error code 0, SQL state XJ001: Java Exception: '4 = 4: java.lang.ArrayIndexOutOfBoundsException'. After throw this exception the database shutdown and lost the connection. I'm updating an application from a previous version of Derby (Bundle-Version: 10.0.201 From derby.jar Manifest) so this query works fine in version 10.0. The Query: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo The deby log entry: 2008-07-07 14:44:51.282 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.3.1.4 - (561794): instance c013800d-011a-fdfb-6fa4-3451d386 on database directory C:\PAD\database Database Class Loader started - derby.database.classpath='' 2008-07-07 14:46:40.506 GMT Thread[SQLExecution,1,system] (XID = 3441038), (SESSIONID = 0), (DATABASE = C:\PAD\database), (DRDAID = null), Cleanup action starting 2008-07-07 14:46:40.506 GMT Thread[SQLExecution,1,system] (XID = 3441038), (SESSIONID = 0), (DATABASE = C:\PAD\database), (DRDAID = null), Failed Statement is: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo java.lang.ArrayIndexOutOfBoundsException: 4 = 4 at java.util.Vector.elementAt(Vector.java:427) at org.apache.derby.impl.sql.compile.QueryTreeNodeVector.elementAt(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumnList.setUnionResultExpression(Unknown Source) at org.apache.derby.impl.sql.compile.SetOperatorNode.buildRCL(Unknown Source) at org.apache.derby.impl.sql.compile.SetOperatorNode.bindResultColumns(Unknown Source) at org.apache.derby.impl.sql.compile.CursorNode.bindStatement(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.netbeans.modules.db.sql.execute.SQLExecuteHelper.execute(SQLExecuteHelper.java:114) at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor.run(SQLEditorSupport.java:479) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986) Cleanup action completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3764) Union Query fail on Derby 10.4.1.3
[ https://issues.apache.org/jira/browse/DERBY-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heleno da Silva Alves updated DERBY-3764: - Attachment: (was: database_test.10.3.zip) Union Query fail on Derby 10.4.1.3 -- Key: DERBY-3764 URL: https://issues.apache.org/jira/browse/DERBY-3764 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.4.1.3 Environment: Windows XP SP2, NetBeans 6.1 (IDE), Pentium 2 Core 512 Ram, Java 1.6.0_05 Reporter: Heleno da Silva Alves Attachments: CONSTAS_REMESSA.sql, database_test.10.0.zip, database_test.10.3.zip Running a Query on Derby 10.4.1.3 and 10.3.1.4 I got this error message: Error code 0, SQL state XJ001: Java Exception: '4 = 4: java.lang.ArrayIndexOutOfBoundsException'. After throw this exception the database shutdown and lost the connection. I'm updating an application from a previous version of Derby (Bundle-Version: 10.0.201 From derby.jar Manifest) so this query works fine in version 10.0. The Query: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo The deby log entry: 2008-07-07 14:44:51.282 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.3.1.4 - (561794): instance c013800d-011a-fdfb-6fa4-3451d386 on database directory C:\PAD\database Database Class Loader started - derby.database.classpath='' 2008-07-07 14:46:40.506 GMT Thread[SQLExecution,1,system] (XID = 3441038), (SESSIONID = 0), (DATABASE = C:\PAD\database), (DRDAID = null), Cleanup action starting 2008-07-07 14:46:40.506 GMT Thread[SQLExecution,1,system] (XID = 3441038), (SESSIONID = 0), (DATABASE = C:\PAD\database), (DRDAID = null), Failed Statement is: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo java.lang.ArrayIndexOutOfBoundsException: 4 = 4 at java.util.Vector.elementAt(Vector.java:427) at org.apache.derby.impl.sql.compile.QueryTreeNodeVector.elementAt(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumnList.setUnionResultExpression(Unknown Source) at org.apache.derby.impl.sql.compile.SetOperatorNode.buildRCL(Unknown Source) at org.apache.derby.impl.sql.compile.SetOperatorNode.bindResultColumns(Unknown Source) at org.apache.derby.impl.sql.compile.CursorNode.bindStatement(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.netbeans.modules.db.sql.execute.SQLExecuteHelper.execute(SQLExecuteHelper.java:114) at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor.run(SQLEditorSupport.java:479) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986) Cleanup action completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3764) Union Query fail on Derby 10.4.1.3
[ https://issues.apache.org/jira/browse/DERBY-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heleno da Silva Alves updated DERBY-3764: - Attachment: database_test.10.3.zip Derby 10.0 - Fail Union Query fail on Derby 10.4.1.3 -- Key: DERBY-3764 URL: https://issues.apache.org/jira/browse/DERBY-3764 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.4.1.3 Environment: Windows XP SP2, NetBeans 6.1 (IDE), Pentium 2 Core 512 Ram, Java 1.6.0_05 Reporter: Heleno da Silva Alves Attachments: CONSTAS_REMESSA.sql, database_test.10.0.zip, database_test.10.3.zip Running a Query on Derby 10.4.1.3 and 10.3.1.4 I got this error message: Error code 0, SQL state XJ001: Java Exception: '4 = 4: java.lang.ArrayIndexOutOfBoundsException'. After throw this exception the database shutdown and lost the connection. I'm updating an application from a previous version of Derby (Bundle-Version: 10.0.201 From derby.jar Manifest) so this query works fine in version 10.0. The Query: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo The deby log entry: 2008-07-07 14:44:51.282 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.3.1.4 - (561794): instance c013800d-011a-fdfb-6fa4-3451d386 on database directory C:\PAD\database Database Class Loader started - derby.database.classpath='' 2008-07-07 14:46:40.506 GMT Thread[SQLExecution,1,system] (XID = 3441038), (SESSIONID = 0), (DATABASE = C:\PAD\database), (DRDAID = null), Cleanup action starting 2008-07-07 14:46:40.506 GMT Thread[SQLExecution,1,system] (XID = 3441038), (SESSIONID = 0), (DATABASE = C:\PAD\database), (DRDAID = null), Failed Statement is: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo java.lang.ArrayIndexOutOfBoundsException: 4 = 4 at java.util.Vector.elementAt(Vector.java:427) at org.apache.derby.impl.sql.compile.QueryTreeNodeVector.elementAt(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumnList.setUnionResultExpression(Unknown Source) at org.apache.derby.impl.sql.compile.SetOperatorNode.buildRCL(Unknown Source) at org.apache.derby.impl.sql.compile.SetOperatorNode.bindResultColumns(Unknown Source) at org.apache.derby.impl.sql.compile.CursorNode.bindStatement(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.netbeans.modules.db.sql.execute.SQLExecuteHelper.execute(SQLExecuteHelper.java:114) at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor.run(SQLEditorSupport.java:479) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986) Cleanup action completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3764) Union Query fail on Derby 10.4.1.3
[ https://issues.apache.org/jira/browse/DERBY-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heleno da Silva Alves updated DERBY-3764: - Attachment: database_test.10.3.zip Derby 10.3.1.4 (NetBeans 6.1) - Fail Union Query fail on Derby 10.4.1.3 -- Key: DERBY-3764 URL: https://issues.apache.org/jira/browse/DERBY-3764 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.4.1.3 Environment: Windows XP SP2, NetBeans 6.1 (IDE), Pentium 2 Core 512 Ram, Java 1.6.0_05 Reporter: Heleno da Silva Alves Attachments: CONSTAS_REMESSA.sql, database_test.10.0.zip, database_test.10.3.zip Running a Query on Derby 10.4.1.3 and 10.3.1.4 I got this error message: Error code 0, SQL state XJ001: Java Exception: '4 = 4: java.lang.ArrayIndexOutOfBoundsException'. After throw this exception the database shutdown and lost the connection. I'm updating an application from a previous version of Derby (Bundle-Version: 10.0.201 From derby.jar Manifest) so this query works fine in version 10.0. The Query: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo The deby log entry: 2008-07-07 14:44:51.282 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.3.1.4 - (561794): instance c013800d-011a-fdfb-6fa4-3451d386 on database directory C:\PAD\database Database Class Loader started - derby.database.classpath='' 2008-07-07 14:46:40.506 GMT Thread[SQLExecution,1,system] (XID = 3441038), (SESSIONID = 0), (DATABASE = C:\PAD\database), (DRDAID = null), Cleanup action starting 2008-07-07 14:46:40.506 GMT Thread[SQLExecution,1,system] (XID = 3441038), (SESSIONID = 0), (DATABASE = C:\PAD\database), (DRDAID = null), Failed Statement is: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo java.lang.ArrayIndexOutOfBoundsException: 4 = 4 at java.util.Vector.elementAt(Vector.java:427) at org.apache.derby.impl.sql.compile.QueryTreeNodeVector.elementAt(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumnList.setUnionResultExpression(Unknown Source) at org.apache.derby.impl.sql.compile.SetOperatorNode.buildRCL(Unknown Source) at org.apache.derby.impl.sql.compile.SetOperatorNode.bindResultColumns(Unknown Source) at org.apache.derby.impl.sql.compile.CursorNode.bindStatement(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.netbeans.modules.db.sql.execute.SQLExecuteHelper.execute(SQLExecuteHelper.java:114) at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor.run(SQLEditorSupport.java:479) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986) Cleanup action completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3764) Union Query fail on Derby 10.4.1.3
[ https://issues.apache.org/jira/browse/DERBY-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heleno da Silva Alves updated DERBY-3764: - Attachment: database_test.10.4.zip Derby 10.4 - Fail Union Query fail on Derby 10.4.1.3 -- Key: DERBY-3764 URL: https://issues.apache.org/jira/browse/DERBY-3764 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.4.1.3 Environment: Windows XP SP2, NetBeans 6.1 (IDE), Pentium 2 Core 512 Ram, Java 1.6.0_05 Reporter: Heleno da Silva Alves Attachments: CONSTAS_REMESSA.sql, database_test.10.0.zip, database_test.10.3.zip, database_test.10.4.zip, export_contas_remessas.exp Running a Query on Derby 10.4.1.3 and 10.3.1.4 I got this error message: Error code 0, SQL state XJ001: Java Exception: '4 = 4: java.lang.ArrayIndexOutOfBoundsException'. After throw this exception the database shutdown and lost the connection. I'm updating an application from a previous version of Derby (Bundle-Version: 10.0.201 From derby.jar Manifest) so this query works fine in version 10.0. The Query: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo The deby log entry: 2008-07-07 14:44:51.282 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.3.1.4 - (561794): instance c013800d-011a-fdfb-6fa4-3451d386 on database directory C:\PAD\database Database Class Loader started - derby.database.classpath='' 2008-07-07 14:46:40.506 GMT Thread[SQLExecution,1,system] (XID = 3441038), (SESSIONID = 0), (DATABASE = C:\PAD\database), (DRDAID = null), Cleanup action starting 2008-07-07 14:46:40.506 GMT Thread[SQLExecution,1,system] (XID = 3441038), (SESSIONID = 0), (DATABASE = C:\PAD\database), (DRDAID = null), Failed Statement is: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo java.lang.ArrayIndexOutOfBoundsException: 4 = 4 at java.util.Vector.elementAt(Vector.java:427) at org.apache.derby.impl.sql.compile.QueryTreeNodeVector.elementAt(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumnList.setUnionResultExpression(Unknown Source) at org.apache.derby.impl.sql.compile.SetOperatorNode.buildRCL(Unknown Source) at org.apache.derby.impl.sql.compile.SetOperatorNode.bindResultColumns(Unknown Source) at org.apache.derby.impl.sql.compile.CursorNode.bindStatement(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.netbeans.modules.db.sql.execute.SQLExecuteHelper.execute(SQLExecuteHelper.java:114) at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor.run(SQLEditorSupport.java:479) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986) Cleanup action completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3764) Union Query fail on Derby 10.4.1.3
[ https://issues.apache.org/jira/browse/DERBY-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heleno da Silva Alves updated DERBY-3764: - Attachment: export_contas_remessas.exp Some Data to CONTAS_REMESSA Table Union Query fail on Derby 10.4.1.3 -- Key: DERBY-3764 URL: https://issues.apache.org/jira/browse/DERBY-3764 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.4.1.3 Environment: Windows XP SP2, NetBeans 6.1 (IDE), Pentium 2 Core 512 Ram, Java 1.6.0_05 Reporter: Heleno da Silva Alves Attachments: CONSTAS_REMESSA.sql, database_test.10.0.zip, database_test.10.3.zip, database_test.10.4.zip, export_contas_remessas.exp Running a Query on Derby 10.4.1.3 and 10.3.1.4 I got this error message: Error code 0, SQL state XJ001: Java Exception: '4 = 4: java.lang.ArrayIndexOutOfBoundsException'. After throw this exception the database shutdown and lost the connection. I'm updating an application from a previous version of Derby (Bundle-Version: 10.0.201 From derby.jar Manifest) so this query works fine in version 10.0. The Query: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo The deby log entry: 2008-07-07 14:44:51.282 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.3.1.4 - (561794): instance c013800d-011a-fdfb-6fa4-3451d386 on database directory C:\PAD\database Database Class Loader started - derby.database.classpath='' 2008-07-07 14:46:40.506 GMT Thread[SQLExecution,1,system] (XID = 3441038), (SESSIONID = 0), (DATABASE = C:\PAD\database), (DRDAID = null), Cleanup action starting 2008-07-07 14:46:40.506 GMT Thread[SQLExecution,1,system] (XID = 3441038), (SESSIONID = 0), (DATABASE = C:\PAD\database), (DRDAID = null), Failed Statement is: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo java.lang.ArrayIndexOutOfBoundsException: 4 = 4 at java.util.Vector.elementAt(Vector.java:427) at org.apache.derby.impl.sql.compile.QueryTreeNodeVector.elementAt(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumnList.setUnionResultExpression(Unknown Source) at org.apache.derby.impl.sql.compile.SetOperatorNode.buildRCL(Unknown Source) at org.apache.derby.impl.sql.compile.SetOperatorNode.bindResultColumns(Unknown Source) at org.apache.derby.impl.sql.compile.CursorNode.bindStatement(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.netbeans.modules.db.sql.execute.SQLExecuteHelper.execute(SQLExecuteHelper.java:114) at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor.run(SQLEditorSupport.java:479) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986) Cleanup action completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3764) Union Query fail on Derby 10.4.1.3
[ https://issues.apache.org/jira/browse/DERBY-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3764: -- Derby Info: [Regression] Derby Categories: [High Value Fix] I verified on trunk using the script to create the table and import data. Here is the debug stack trace. The latest on the 10.2 looks ok. The problem seems to start with 10.3. Marking as a regression. ij select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira from contas_remessa rec where cd_tipo = 1105 and cd_conta = 4 group by rec.cd_conta, rec.ds_conta union select case when cd_tipo = 170 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_anterior , case when cd_tipo = 175 then sum(vlr_contabil) + sum(vlr_ajuste) else 0 end vlr_proc_atual , 0 disp_financeira from contas_remessa where cd_tipo in (170, 175) and status = 'S' group by cd_tipo ; ERROR XJ001: Java exception: 'Array index out of range: 4: java.lang.ArrayIndexOutOfBoundsException'. java.sql.SQLException: Java exception: 'Array index out of range: 4: java.lang.ArrayIndexOutOfBoundsException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:87) at org.apache.derby.impl.jdbc.Util.javaException(Util.java:244) 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:2183) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:614) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:555) at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:329) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:508) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:350) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:248) 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.Main.main(Main.java:73) at org.apache.derby.tools.ij.main(ij.java:59) Caused by: java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 4 at java.util.Vector.elementAt(Vector.java:266) at org.apache.derby.impl.sql.compile.QueryTreeNodeVector.elementAt(QueryTreeNodeVector.java:51) at org.apache.derby.impl.sql.compile.ResultColumnList.setUnionResultExpression(ResultColumnList.java:2242) at org.apache.derby.impl.sql.compile.SetOperatorNode.buildRCL(SetOperatorNode.java:631) at org.apache.derby.impl.sql.compile.SetOperatorNode.bindResultColumns(SetOperatorNode.java:558) at org.apache.derby.impl.sql.compile.CursorNode.bindStatement(CursorNode.java:239) 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:794) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:606) ... 9 more ij Union Query fail on Derby 10.4.1.3 -- Key: DERBY-3764 URL: https://issues.apache.org/jira/browse/DERBY-3764 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4, 10.4.1.3 Environment: Windows XP SP2, NetBeans 6.1 (IDE), Pentium 2 Core 512 Ram, Java 1.6.0_05 Reporter: Heleno da Silva Alves Attachments: CONSTAS_REMESSA.sql, database_test.10.0.zip, database_test.10.3.zip, database_test.10.4.zip, export_contas_remessas.exp Running a Query on Derby 10.4.1.3 and 10.3.1.4 I got this error message: Error code 0, SQL state XJ001: Java Exception: '4 = 4: java.lang.ArrayIndexOutOfBoundsException'. After throw this exception the database shutdown and lost the connection. I'm updating an application from a previous version of Derby (Bundle-Version: 10.0.201 From derby.jar Manifest) so this query works fine in version 10.0. The Query: select 0 vlr_proc_anterior , 0 vlr_proc_atual , sum(vlr_contabil + vlr_ajuste) disp_financeira
Regression Test Report - tinderbox_trunk16 674473 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 674473/2008-07-07 14:42:33 CEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 022 0 115.78% org.apache.derbyTesting.functionTests.tests.demo._Suite F:2,E:01019710195 0 1679.17% org.apache.derbyTesting.functionTests.suites.All 0261261 0 110.78% derbyall 022 0 167.85% org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.CompatibilityCombinations F:1,E:087 0 107.46% org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationSuite Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-674473.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/674473_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/674473.txt ( All results in http://dbtg.thresher.com/derby/test/ )
HighValueFixCandidate page
I plan to update Jira bugs with the High Value Fix Candidate category and just link to the jira query from the HighValueFixCandidate page. This will mean we will lose the comments, but hopefully will make the HighValueFixCandidates list easier to maintain and encourage more community involvement in marking candidates. Please let me know if you have any issues with this change. Kathey
[jira] Updated: (DERBY-3634) Cannot use row_number() in ORDER BY clause
[ https://issues.apache.org/jira/browse/DERBY-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3634: -- Derby Categories: [High Value Fix] Cannot use row_number() in ORDER BY clause -- Key: DERBY-3634 URL: https://issues.apache.org/jira/browse/DERBY-3634 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.1.3 Reporter: Rick Hillegas The following query works correctly: select abs(a), row_number() over () from t where a 100 and a 111 order by abs(a) I expected the following query to also work, but it raised an exception: select abs(a), row_number() over () from t where a 100 and a 111 order by row_number() over () This is the error I saw: ERROR 42X01: Syntax error: Encountered over at line 5, column 23. Here are the reasons why I think that this syntax is supposed to be supported: According to my reading of the 2003 SQL spec, the ORDER BY clause should be able to sort on any expression in the SELECT list. That includes OLAP expressions. I believe this is so because, according to part 2, section 10.10 (sort specification), a sort key can be any value expression and if you follow the grammar for value expression, it can resolve to be a value expression primary (see section 6.3), which can in turn resolve to be a window function. This reasoning is supported by tracing the hotlinks on the following page which lays out the SQL 2003 BNF: http://savage.net.au/SQL/sql-2003-2.bnf.html This interpretation is further supported by the example of an ORDER BY clause referencing an OLAP expression which is provided on page 23 of the introduction to OLAP written by Fred Zemke, Krishna Kulkarni, Andy Witkowski, and Bob Lyle: www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/OLAP-99-154r2.pdf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3590) Hang in suites.All on Linux with IBM 1.6
[ https://issues.apache.org/jira/browse/DERBY-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden closed DERBY-3590. - Resolution: Invalid Closing this issue because it is a JVM issue. There should be a fix with the upcoming IBM 1.6 SR2 release. Hang in suites.All on Linux with IBM 1.6 - Key: DERBY-3590 URL: https://issues.apache.org/jira/browse/DERBY-3590 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.5.0.0 Environment: SUSE LInux with java version: java version 1.6.0 Java(TM) SE Runtime Environment (build pxi3260sr1-20080307_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20080305_17755 (JIT enabled, AOT enabled) J9VM - 20080305_017755_lHdSMr JIT - r9_20080304_1821 GC - 20080305_AB) JCL - 20080301_01 Reporter: Kathey Marsden Assignee: Kathey Marsden Attachments: javacore.zip With IBM 1.6 suites.All will hang after finishing testUpdatePurgedTuple1 with the following message in the derby.log Could not listen on port 1527 on host 127.0.0.1: java.net.BindException: Address already in use An exception was thrown during network server startup. DRDA_ListenPort.S:Could not listen on port 1527 on host 127.0.0.1: java.net.BindException: Address already in use java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:599) at org.apache.derby.iapi.jdbc.DRDAServerStarter.run(Unknown Source) at java.lang.Thread.run(Thread.java:735) Caused by: java.lang.Exception: DRDA_ListenPort.S:Could not listen on port 1527 on host 127.0.0.1: java.net.BindException: Address already in use at org.apache.derby.impl.drda.NetworkServerControlImpl.consolePropertyMessageWork(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.consolePropertyMessage(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(Unknown Source) ... 5 more The server seems to be partially up. Any attempt to ping it will hang I will attach the javacore with the thread dump. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3393) Database corruption when adding sleep() in RAFContainer4.writePage()
[
https://issues.apache.org/jira/browse/DERBY-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-3393:
--
Derby Categories: [High Value Fix]
Database corruption when adding sleep() in RAFContainer4.writePage()
Key: DERBY-3393
URL: https://issues.apache.org/jira/browse/DERBY-3393
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.2.2.1, 10.3.1.4, 10.4.1.3
Environment: Solaris 10, OpenSolaris snv_80, Sun Java SE 5.0, Sun
Java SE 6, Derby trunk #618305
Reporter: Knut Anders Hatlen
Priority: Critical
In order to test whether RAFContainer4.writePage() was properly synchronized,
I made it sleep for 100 ms each time after it had written a page, right
before it set its needsSync flag to true, like this:
Index: java/engine/org/apache/derby/impl/store/raw/data/RAFContainer4.java
===
--- java/engine/org/apache/derby/impl/store/raw/data/RAFContainer4.java
(revision 618305)
+++ java/engine/org/apache/derby/impl/store/raw/data/RAFContainer4.java
(working copy)
@@ -350,6 +350,11 @@
dataFactory.writeFinished();
}
} else {
+try {
+Thread.sleep(100);
+} catch (InterruptedException ie) {
+// ignored
+}
synchronized(this) {
needsSync = true;
}
When I ran derbyall with this change, I saw some failures in the
storerecovery suite. I reran the storerecovery suite a couple of times,
seeing failures each time, although the actual failures varied a bit.
The most common failure was the following (page numbers and container numbers
varied):
Exception in thread main java.sql.SQLException: Failed to start database
'wombat', see the next exception for details.
Caused by: java.sql.SQLException: Failed to start database 'wombat', see
the next exception for details.
... 17 more
Caused by: java.sql.SQLException: Page Page(19,Container(0, 1073)) is at
version 0, the log file contains change version 578, either there are log
records of this page missing, or this page did not get written out to disk
properly.
... 14 more
Caused by: ERROR XSDB4: Page Page(19,Container(0, 1073)) is at version 0,
the log file contains change version 578, either there are log records of
this page missing, or this page did not get written out to disk properly.
... 14 more
This failure was seen in oc_rec3, oc_rec4, dropcrash and dropcrash2.
In some cases, I saw this failure in oc_rec3
Exception while trying to insert row number: 0
ERROR XBCA0: Cannot create new object with key Page(2,Container(0, 1040))
in PageCache cache. The object already exists in the cache.
which would be followed by this error in oc_rec4:
ERROR 23505: The statement was aborted because it would have caused a
duplicate key value in a unique or primary key constraint or unique index
identified by 'TEST1_2_IDX_INDCOL3' defined on 'TEST1_2'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3390) SQLException thrown from user function kills network connection
[
https://issues.apache.org/jira/browse/DERBY-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-3390:
--
Derby Categories: [High Value Fix]
SQLException thrown from user function kills network connection
---
Key: DERBY-3390
URL: https://issues.apache.org/jira/browse/DERBY-3390
Project: Derby
Issue Type: Bug
Components: Network Server
Affects Versions: 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1
Reporter: Rick Hillegas
Thanks to Frank Griffin for pointing out this issue in a derby-dev email
thread:
http://www.nabble.com/SQLException-thrown-from-Table-Function-ResultSet-to15241332.html#a15241332
If a user-coded function throws a SQLException, Derby will try to cast the
exception to a Derby exception class before shipping the exception to the
network client. This raises a ClassCastException and kills the connection. I
have observed this in 10.4, 10.3, 10.2, and 10.1. You can reproduce this
problem with the following function class and sql script.
The function class:
import java.sql.*;
public class BadFunction
{
/**
* p
* This function just throws a SQLException.
* /p
*/
public static int badFunction()
throws SQLException
{
throw new SQLException( I refuse to return an int! );
}
}
Here is the SQL script:
connect 'jdbc:derby://localhost:8246/derby10.4';
drop function badFunction;
create function badFunction()
returns int
language java
parameter style java
no sql
external name 'BadFunction.badFunction'
;
values ( badFunction() );
values ( badFunction() );
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3395) 'An ON clause associated with a JOIN operator is not valid.' failure with 10.3.2.1 passes with 10.2
[ https://issues.apache.org/jira/browse/DERBY-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-3395. --- Resolution: Duplicate This issue was opened in error. It is a duplicate of DERBY-39. 'An ON clause associated with a JOIN operator is not valid.' failure with 10.3.2.1 passes with 10.2 --- Key: DERBY-3395 URL: https://issues.apache.org/jira/browse/DERBY-3395 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.1.3 Reporter: Kathey Marsden There is a reproduction attached to DERBY-39 derby-joinon.tar.gz which causes the error: This is a regresion in 10.3.1.4. It works fine with 10.2.2.0. It is therefore a different issue than DERBY-39 which was reported against 10.0.20. In 10.3 the stack trace is below: java.sql.SQLSyntaxErrorException: An ON clause associated with a JOIN operator is not valid. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:91) 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:1573) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(EmbedPreparedStatement.java:144) at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Driver40.java:105) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(EmbedConnection.java:923) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(EmbedConnection.java:751) at SubShape.insert(SubShape.java:56) at org.apache.derby.exe.ac12564092x0117xf043xb4ffx001487781.g0(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:599) at org.apache.derby.impl.services.reflect.ReflectMethod.invoke(ReflectMethod.java:46) at org.apache.derby.impl.sql.execute.CallStatementResultSet.open(CallStatementResultSet.java:74) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:370) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(GenericTriggerExecutor.java:173) at org.apache.derby.impl.sql.execute.StatementTriggerExecutor.fireTrigger(StatementTriggerExecutor.java:80) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(TriggerEventActivator.java:278) at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1163) at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:497) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:370) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1203) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:596) 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: java.sql.SQLException: An ON clause associated with a JOIN operator is not valid. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:13 5) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) ... 35 more Caused by: ERROR 42972: An ON clause associated with a JOIN operator is not
[jira] Commented: (DERBY-1488) Provide an Eclipse feature for the org.apache.derby.core plug-in
[ https://issues.apache.org/jira/browse/DERBY-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611297#action_12611297 ] Steve Bate commented on DERBY-1488: --- Even without an update site, the feature packaging would make it easier to install the plugin locally using the Eclipse 3.4 update manager. Provide an Eclipse feature for the org.apache.derby.core plug-in Key: DERBY-1488 URL: https://issues.apache.org/jira/browse/DERBY-1488 Project: Derby Issue Type: Improvement Components: Eclipse Plug-in Reporter: Ian Leslie Priority: Minor Attachments: derby_core_plugin_feature_10.1.3.zip, DerbyAboutBox.PNG, DerbyInAboutBox.PNG I recently upgraded to 10.1.3.1 and was pleased to see an eclipse plug-in available. Previously I had been rolling my own out of the regular install. I am using Derby in an RCP application and therefore have a desire to have a feature too. In order for the Derby information to appear with the Derby Logo at the top level of an RCP application's about box there needs to be a feature as well as a plug-in. I suggest that a feature be created for the .core plug-in and that the .core plug-in have Eclipse branding information added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3266) Not possible for non-db-owner to create a temporary table. Get ERROR 42507: User 'USERB' can not perform the operation in schema 'SESSION'.
[
https://issues.apache.org/jira/browse/DERBY-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-3266:
--
Derby Categories: [High Value Fix]
Not possible for non-db-owner to create a temporary table. Get ERROR 42507:
User 'USERB' can not perform the operation in schema 'SESSION'.
-
Key: DERBY-3266
URL: https://issues.apache.org/jira/browse/DERBY-3266
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.3.1.4
Environment: Linux 2.6.17-5mdv
Reporter: adam jvok
It seems that only the owner of a database may create tempoary tables in that
db.
This is not helpful as many other users may want to run a query on that db
that relies upon the creation of temporary tables.
I would expect non-db-owners to be able create temporay tables.
The problem is demonstrated with:
derby.properties like this:
derby.connection.requireAuthentication=true
derby.authentication.provider=BUILTIN
derby.database.sqlAuthorization=TRUE
derby.user.usera=pwd
derby.fullAccessUsers=usera
derby.drda.host=192.168.1.50
Start the network server and run up 'ij'.
ijconnect
'jdbc:derby://192.168.1.50:1527/TEST1;user=usera;password=pwd;create=true;';
ij declare global temporary table t11(a int) on commit preserve rows
not logged;
0 rows inserted/updated/deleted
All good so far.
Now try this (while still connected as usera):
ij call SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.user.userb','pwd');
Statement executed.
ij call SYSCS_UTIL.SYSCS_SET_USER_ACCESS('userb','FULLACCESS');
Statement executed.
ij disconnect;
ij connect 'jdbc:derby://192.168.1.50:1527/TEST1;user=userb;password=pwd;';
ij declare global temporary table t1(a int) on commit preserve rows not
logged;
ERROR 42507: User 'USERB' can not perform the operation in schema 'SESSION'.
SYSINFO:
-- Java Information --
Java Version:1.6.0_02-ea
Java Vendor: Sun Microsystems Inc.
Java home: /usr/java/jdk1.6.0_02/jre
Java classpath:
/home/ajvok/derby/db-derby-10.3.1.4-bin/lib/derby.jar:/home/ajvok/derby/db-derby-10.3.1.4-bin/lib/derbynet.jar:/home/ajvok/derby/db-derby-
10.3.1.4-bin/lib/derbytools.jar:/home/ajvok/derby/db-derby-10.3.1.4-bin/lib/derbyclient.jar:/home/ajvok/derby/local/sp1.jar
OS name: Linux
OS architecture: i386
OS version: 2.6.17-5mdv
Java user name: ajvok
Java user home: /home/ajvok
Java user dir: /home/ajvok/derby/local
java.specification.name: Java Platform API Specification
java.specification.version: 1.6
- Derby Information
JRE - JDBC: Java SE 6 - JDBC 4.0
[/home/ajvok/derby/db-derby-10.3.1.4-bin/lib/derby.jar] 10.3.1.4 - (561794)
[/home/ajvok/derby/db-derby-10.3.1.4-bin/lib/derbytools.jar] 10.3.1.4 -
(561794)
[/home/ajvok/derby/db-derby-10.3.1.4-bin/lib/derbynet.jar] 10.3.1.4 - (561794)
[/home/ajvok/derby/db-derby-10.3.1.4-bin/lib/derbyclient.jar] 10.3.1.4 -
(561794)
--
- Locale Information -
Current Locale : [English/United Kingdom [en_GB]]
Found support for locale: [cs]
version: 10.3.1.4 - (561794)
Found support for locale: [de_DE]
version: 10.3.1.4 - (561794)
Found support for locale: [es]
version: 10.3.1.4 - (561794)
Found support for locale: [fr]
version: 10.3.1.4 - (561794)
Found support for locale: [hu]
version: 10.3.1.4 - (561794)
Found support for locale: [it]
version: 10.3.1.4 - (561794)
Found support for locale: [ja_JP]
version: 10.3.1.4 - (561794)
Found support for locale: [ko_KR]
version: 10.3.1.4 - (561794)
Found support for locale: [pl]
version: 10.3.1.4 - (561794)
Found support for locale: [pt_BR]
version: 10.3.1.4 - (561794)
Found support for locale: [ru]
version: 10.3.1.4 - (561794)
Found support for locale: [zh_CN]
version: 10.3.1.4 - (561794)
Found support for locale: [zh_TW]
version: 10.3.1.4 - (561794)
--
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3091) NullPointerException executing SYSCS_UTIL.SYSCS_IMPORT_TABLE when derby.language.logQueryPlan=true
[
https://issues.apache.org/jira/browse/DERBY-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden resolved DERBY-3091.
---
Resolution: Fixed
Fix Version/s: 10.3.1.4
According to the comments this is fixed in 10.3.1.4
NullPointerException executing SYSCS_UTIL.SYSCS_IMPORT_TABLE when
derby.language.logQueryPlan=true
--
Key: DERBY-3091
URL: https://issues.apache.org/jira/browse/DERBY-3091
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.1.6
Environment: -- Java Information --
Java Version:1.6.0_01
Java Vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jre1.6.0_01
Java classpath: C:\Program
Files\Java\jdk1.6.0_01\db\lib\derby.jar;C:\Program F
iles\Java\jdk1.6.0_01\db\lib\derbytools.jar;.;C:\Program
Files\Java\jre1.6.0_01\
lib\ext\QTJava.zip
OS name: Windows XP
OS architecture: x86
OS version: 5.1
Java user name: Chip
Java user home: C:\Documents and Settings\Chip
Java user dir: C:\Documents and Settings\Chip\Desktop
java.specification.name: Java Platform API Specification
java.specification.version: 1.6
- Derby Information
JRE - JDBC: Java SE 6 - JDBC 4.0
[C:\Program Files\Java\jdk1.6.0_01\db\lib\derby.jar] 10.2.1.7 - (453926)
[C:\Program Files\Java\jdk1.6.0_01\db\lib\derbytools.jar] 10.2.1.7 - (453926)
Reporter: Chip Hartney
Fix For: 10.3.1.4
Attachments: 20070724-124300-ZJVTERMS.dat
Derby throws NullPointerException when executing an IMPORT if logging of
query plans is turned on in the derby.properties file as in:
derby.language.logQueryPlan=true
If logging is turned off, the failure does not occur and the table is
successfully loaded.
I am using the version of Derby that is provided with Java 6.
Java source code is:
Statement stmt = oCnxn.createStatement();
try {
stmt.execute(CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE ('TEMP',
'ZJVTERMS',
'C:\DOCUME~1\Chip\LOCALS~1\Temp\20070724-124300-ZJVTERMS.dat',';','~',null,
1));
} finally {
stmt.close();
}
Derby log output is:
2007-09-27 15:29:06.843 GMT Thread[AWT-EventQueue-0,6,main] (XID = 311121),
(SESSIONID = 0), INSERT INTO TEMP.ZJVTERMS(CODE, TEXT) PROPERTIES
insertMode=replace SELECT cast(COLUMN1 AS INTEGER) , COLUMN2 from new
org.apache.derby.impl.load.Import('C:\DOCUME~1\Chip\LOCALS~1\Temp\20070724-124300-ZJVTERMS.dat',';','~',null,
2 ) AS importvti *** Insert ResultSet using table locking:
deferred: false
insert mode: bulk insert
Rows inserted = 22
Indexes updated = 0
Execute Time = 0
Normalize ResultSet:
Number of opens = 1
Rows seen = 22
constructor time (milliseconds) = 0
open time (milliseconds) = 0
next time (milliseconds) = 0
close time (milliseconds) = 0
optimizer estimated row count:1.00
optimizer estimated cost: 10.00
Source result set:
Project-Restrict ResultSet (2):
Number of opens = 1
Rows seen = 22
Rows filtered = 0
restriction = false
projection = true
constructor time (milliseconds) = 0
open time (milliseconds) = 0
next time (milliseconds) = 0
close time (milliseconds) = 0
restriction time (milliseconds) = 0
projection time (milliseconds) = 0
optimizer estimated row count:1.00
optimizer estimated cost: 10.00
Source result set:
VTI ResultSet for org.apache.derby.impl.load.Import:
Number of opens = 1
Rows seen = 22
constructor time (milliseconds) = 0
open time (milliseconds) = 0
next time (milliseconds) = 0
close time (milliseconds) = 0
optimizer estimated row count:1.00
optimizer estimated cost: 10.00
2007-09-27 15:29:06.875 GMT Thread[AWT-EventQueue-0,6,main] (XID = 311199),
(SESSIONID = 0), (DATABASE = OrderEntryDB), (DRDAID = null), Cleanup action
starting
2007-09-27 15:29:06.875 GMT Thread[AWT-EventQueue-0,6,main] (XID = 311199),
(SESSIONID = 0), (DATABASE = OrderEntryDB), (DRDAID = null), Failed Statement
is: null
java.lang.NullPointerException evaluating expression
[jira] Updated: (DERBY-2992) getBinaryStream returns incorrect result (truncated value) if underlying blob is deleted
[ https://issues.apache.org/jira/browse/DERBY-2992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2992: -- Derby Categories: [High Value Fix, Wrong query result] getBinaryStream returns incorrect result (truncated value) if underlying blob is deleted Key: DERBY-2992 URL: https://issues.apache.org/jira/browse/DERBY-2992 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.2.2.0, 10.3.1.4, 10.4.1.3 Reporter: Kathey Marsden Attachments: TruncatedBlob.java If getBinaryStream is reading a value (READ_UNCOMMITTED) and the row is deleted by another connection, a truncated value will be returned without error. I believe instead either the whole value or an IOException should occur. With 10.2 and higher with the repro attahed we get: java TruncatedBlob Embedded: Read 32669 bytes 0 rows in BLOBCLOB With 10.1 Embedded: Read 4 bytes (OK) 0 rows in BLOBCLOB Note network server returns the full value for both 10.1 and 10.2 but gives a lock timeout for 10.2+. I will file a separate issue for that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2990) ResultSet.getBlob holds locks even with READ_UNCOMMITTED isolation level
[ https://issues.apache.org/jira/browse/DERBY-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-2990. --- Resolution: Won't Fix Øystein indicated that the current behavior is intentional. ResultSet.getBlob holds locks even with READ_UNCOMMITTED isolation level Key: DERBY-2990 URL: https://issues.apache.org/jira/browse/DERBY-2990 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.1.4, 10.4.1.3 Reporter: Kathey Marsden Attachments: GetBlobLocks.java ResultSet.getBlob() holds locks even when isolation level is set to TRANSACTION_READ_UNCOMMITTED. See attached repro java GetBlobLocks Exception in thread main ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.services.locks.LockSet.lockObject(Unknown Source) at org.apache.derby.impl.services.locks.SinglePool.lockAnObject(Unknown Source) at org.apache.derby.impl.services.locks.SinglePool.lockObject(Unknown Source) at org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForWrite(Unknown Source) at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.lockPositionForWrite(Unknown Source) at org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.delete(Unknown Source) at org.apache.derby.impl.sql.execute.RowChangerImpl.deleteRow(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.collectAffectedRows(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown Source) at GetBlobLocks.testBlobLocks(GetBlobLocks.java:46) at GetBlobLocks.main(GetBlobLocks.java:11) [C:/kmarsden/repro/getblob] echo $WS -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2970) Hibernate Joins fail if you use Derby (aliases in select clause trump aliases in from and where clauses)
[ https://issues.apache.org/jira/browse/DERBY-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-2970. --- Resolution: Cannot Reproduce Asked for a reproducible test case in February and haven't got anything yet. Closing CNR. The issue can be reopened if we get a repro. Hibernate Joins fail if you use Derby (aliases in select clause trump aliases in from and where clauses) Key: DERBY-2970 URL: https://issues.apache.org/jira/browse/DERBY-2970 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.1.4 Environment: Hibernate v3, Derby 10.3.1.2, Sun's Java 1.6.0_01 Reporter: Charlie Hubbard Using hibernate to do a simple join causes an unknown field exception from derby's libraries. Hibernate uses a mixture of aliases to specify the select clause which is different from the aliases used in the from and where clauses. While strange this is perfectly legal to do. My tables have a very simple structure. Customer has many licenses and they are linked by the shared customer ID field. So it looks something like: Customers: --- id : identity name : varchar(80) ... LicenseKeys: - id : identity CustomerID : int LicenseKey : varchar(256) ... Here is the HQL I tried to execute against the DB: select c, key from Customer c join c.keys as key where key.expirationDate current_timestamp() or key.maintenanceDate current_timestamp() Here is the SQL generated by hibernate: Hibernate: select customer0_.id as id0_0_, keys1_.id as id1_1_, customer0_.address as address0_0_, customer0_.city as city0_0_, customer0_.company as company0_0_, customer0_.email as email0_0_, customer0_.name as name0_0_, customer0_.state as state0_0_, customer0_.zipcode as zipcode0_0_, keys1_.creationDate as creation2_1_1_, keys1_.CustomerID as CustomerID1_1_, keys1_.expirationDate as expirati3_1_1_, keys1_.licenseKey as licenseKey1_1_, keys1_.maintenanceDate as maintena5_1_1_, keys1_.serialNumber as serialNu6_1_1_, keys1_.trial as trial1_1_ from APP.Customers customer0_ inner join APP.LicenseKeys keys1_ on customer0_.id=keys1_.CustomerID where keys1_.expirationDatecurrent timestamp or keys1_.maintenanceDatecurrent timestamp Here is the error coming out of my log file: 2007-07-24 09:48:38,357 [btpool0-4] WARN org.hibernate.util.JDBCExceptionReporter - SQL Error: 3, SQLState: 42X04 2007-07-24 09:48:38,357 [btpool0-4] ERROR org.hibernate.util.JDBCExceptionReporter - Column 'CUSTOMER0_.ID' is either not in any table in the FROM list or appears within a join specification and is outside the scope of the join specification or appears in a HAVING clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'CUSTOMER0_.ID' is not a column in the target table. 2007-07-24 09:48:40,107 [Mail loader] INFO com.emailarchive.demon.MailDemonLoader - Completed polling cycle in 922 ms. Found 0 messages. 2007-07-24 09:48:40,482 [btpool0-4] WARN org.hibernate.util.JDBCExceptionReporter - SQL Warning: 1, SQLState: 01J01 2007-07-24 09:48:40,482 [btpool0-4] WARN org.hibernate.util.JDBCExceptionReporter - Database 'webapps/licensingserver/WEB-INF/licensing' not created, connection made to existing database instead. 2007-07-24 09:48:40.482::WARN: EXCEPTION net.sourceforge.stripes.exception.StripesServletException: Unhandled exception caught by the default exception handler. at net.sourceforge.stripes.exception.DefaultExceptionHandler.handle(DefaultExceptionHandler.java:40) at net.sourceforge.stripes.controller.StripesFilter.doFilter(StripesFilter.java:184) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at
[jira] Updated: (DERBY-2905) Shutting down embedded Derby does not remove all code, the AutoloadDriver is left registered in the DriverManager.
[ https://issues.apache.org/jira/browse/DERBY-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2905: -- Derby Categories: [High Value Fix] Ramin, are you still working on this issue. It would be good to unassign yourself if you are not. Shutting down embedded Derby does not remove all code, the AutoloadDriver is left registered in the DriverManager. -- Key: DERBY-2905 URL: https://issues.apache.org/jira/browse/DERBY-2905 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.2.2.0, 10.3.1.4, 10.4.1.3 Reporter: Daniel John Debrunner Assignee: Ramin Moazeni Attachments: DERBY-2905v0.diff, DERBY-2905v0.stat, DERBY-2905v1.diff, DERBY-2905v1.stat, DERBY-2905v3.diff, DERBY-2905v3.stat, Main.java, Mainv1.java After a shutdown of the embedded driver the AutoloadDriver is not unregistered from DriverManager. However it does not support any future loading of connections so it has no value in remaining registered. Since the DriverManager class will remain forever, this means the Derby code will remain forever in the JVM, even if Derby was loaded by a separate class loader. Regression from 10.1 since before the AutoloadedDriver the internal driver did unregister itself from the DriverManager on a shutdown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2835) Getting SQLState.LANG_IGNORE_MISSING_INDEX_ROW_DURING_DELETE
[ https://issues.apache.org/jira/browse/DERBY-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611302#action_12611302 ] Kathey Marsden commented on DERBY-2835: --- Is this still an issue? I am thinking of closing this issue cannot reproduce. Please let me know if there are any objections. Getting SQLState.LANG_IGNORE_MISSING_INDEX_ROW_DURING_DELETE Key: DERBY-2835 URL: https://issues.apache.org/jira/browse/DERBY-2835 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.2.2.0 Environment: Sun JDK 1.5 Reporter: Kurt Huwig I get messages like this about once a week: WARNING: While deleting a row from a table the index row for base table row (50813,81) was not found in index with conglomerate id 1.297. This problem has automatically been corrected as part of the delete operation. I do not have a reproducing example besides the productive server, so here some hints what it is doing and what happened the last few days: The table in question is a log file which gets a lot of updates and once it reaches a certain limit, the oldest records will be deleted once per day. The database is embedded and accessed both embedded and via one network client on another machine. Nearly all read/write requests come from the network client. The table's size is about 3,8 GB and contains a lot of entries (cannot check right now). The JVM is sometimes stopped via killall java. Both machines are Linux-SMP. Both machines use HA-JDBC to access the database. Both machines have 1,5GB of memory. The JVM is started with -Xmx768M -Xms768M -Xss128k The application uses no transactions on this table. The network client used 4000+ simultaneous connections, sometimes reaching the ulimit of the machine. The number of connections has been reduced to 1/10 and the ulimit has been increased a few days ago. Still there are records in the database from this time. The network connection sometimes broke down as described in DERBY-2747. The network client gets lock timeouts several times a day, due to long running requests. The network client had a OutOfMemoryException regarding the Heap some days ago. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2769) Implement error handling/parameter checking in Clob.setString
[ https://issues.apache.org/jira/browse/DERBY-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2769: -- Derby Categories: [Newcomer] Implement error handling/parameter checking in Clob.setString - Key: DERBY-2769 URL: https://issues.apache.org/jira/browse/DERBY-2769 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.3.1.4 Reporter: Kristian Waagan The error handling, or parameter checking, in Clob.subString is not adequate. There are four parameters that can be invalid; * pos * str * offset * len The first one is already handled properly, the remaining three are not. They typically result in some low-level exception like a NPE. I have not found anything in the JDBC specification nor JavaDoc that dictates the behavior, except for that SQLException should use states defined in the SQL 2003 specification. A brief search there resulted in the following possibilities: 22003 - numeric value out of range 22004 - null value not allowed 2200F - zero-length character string 22011 - substring error 22023 - invalid parameter value Some of these are already defined by Derby, but with unsuitable or very specific error messages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2749) Client connection closed during heavy load connections to network server
[ https://issues.apache.org/jira/browse/DERBY-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611303#action_12611303 ] Kathey Marsden commented on DERBY-2749: --- Can we close this cannot reproduce? Client connection closed during heavy load connections to network server Key: DERBY-2749 URL: https://issues.apache.org/jira/browse/DERBY-2749 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.2.2.0 Environment: Sun JDK 1.5.0 Reporter: Kurt Huwig I am using HA-JDBC to cluster two machines with ~3,5 GB of data. It is a mailserver which gets about 100 mails per minute with each mail causing several SQL reads and writes. After synchronizing the 3,5 GB which takes around 15 minutes, soon after that I get this exception: Caused by: java.sql.SQLException: Unzureichende Daten beim Lesen aus dem Netz. Erwartet wurden mindestens 6 Bytes, empfangen wurden jedoch nur -1 Bytes. Die Verbindung wurde beendet. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeUpdate(Unknown Source) at net.sf.hajdbc.sql.PreparedStatement$5.execute(PreparedStatement.java:144) at net.sf.hajdbc.sql.PreparedStatement$5.execute(PreparedStatement.java:142) at net.sf.hajdbc.sql.SQLObject$1.call(SQLObject.java:390) at net.sf.hajdbc.util.concurrent.SynchronousExecutor$SynchronousFuture.init(SynchronousExecutor.java:178) at net.sf.hajdbc.util.concurrent.SynchronousExecutor.submit(SynchronousExecutor.java:89) at net.sf.hajdbc.sql.SQLObject.executeWriteToDatabase(SQLObject.java:394) ... 11 more Caused by: org.apache.derby.client.am.DisconnectException: Unzureichende Daten beim Lesen aus dem Netz. Erwartet wurden mindestens 6 Bytes, empfangen wurden jedoch nur -1 Bytes. Die Verbindung wurde beendet. at org.apache.derby.client.net.Reply.fill(Unknown Source) at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Unknown Source) at org.apache.derby.client.net.Reply.readDssHeader(Unknown Source) at org.apache.derby.client.net.Reply.startSameIdChainParse(Unknown Source) at org.apache.derby.client.net.NetStatementReply.readExecute(Unknown Source) at org.apache.derby.client.net.StatementReply.readExecute(Unknown Source) at org.apache.derby.client.net.NetPreparedStatement.readExecute_(Unknown Source) at org.apache.derby.client.am.PreparedStatement.readExecute(Unknown Source) at org.apache.derby.client.am.PreparedStatement.flowExecute(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeUpdateX(Unknown Source) ... 18 more The number of bytes read is in fact 0; I filed DERBY-2747 for this. I think the reason for this is the server issuing a Socket.close(). This seems to be called only by DRDAConnThread.closeSession() which is called by - DRDAConnThread.handleException(Exception) - DRDAConnThread.run() - DRDAConnThread.sessionInitialState() I did not set any timeslice, so the bugs mentioned in DERBY-2026 and DERBY-2748 should not apply. A timeout cannot happen on the client, as this would yield a SocketTimeoutException and not a read() of -1, so for some reason I believe, the server seems to close the connection. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2747) Reply incorrectly handles read() returning -1
[ https://issues.apache.org/jira/browse/DERBY-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2747: -- Derby Categories: [High Value Fix] This looks like it is still an issue. Patch just needs testing and commit. I don't think we need an ICLA for this. Reply incorrectly handles read() returning -1 - Key: DERBY-2747 URL: https://issues.apache.org/jira/browse/DERBY-2747 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.2.2.0 Reporter: Kurt Huwig Priority: Minor Attachments: patch-2747-1.diff, patch-2747-2.diff If java/client/org/apache/derby/client/net/Reply.java encounters a EOF, i.e. reads -1 then it adds this value to the number of bytes read and prints an error message which reads -1 bytes read. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2732) Loosing connection after a number of syntax errors while running a query
[ https://issues.apache.org/jira/browse/DERBY-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-2732. --- Resolution: Cannot Reproduce Cannot reproduce this issue. Please reopen if you get a repro. Loosing connection after a number of syntax errors while running a query Key: DERBY-2732 URL: https://issues.apache.org/jira/browse/DERBY-2732 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.3.1.4 Environment: java version 1.5.0_02 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09) Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode) sysinfo --- -- Java Information -- Java Version:1.5.0_02 Java Vendor: Sun Microsystems Inc. Java home: c:\p4client\mkutty_ltmain\jdk15\jre Java classpath: c:/pantry/db2jcc.jar;c:/pantry/db2jcc_license_c.jar;c:/pantry/d erby.jar;c:/pantry/derbyclient.jar;c:/pantry/derbyLocale_de_DW.jar;c:/pantry/der byLocale_es.jar;c:/pantry/derbyLocale_fr.jar;c:/pantry/derbyLocale_it.jar;c:/pan try/derbyLocale_ja_JP.jar;c:/pantry/derbyLocale_ko_KR.jar;c:/pantry/derbyLocale_ pt_BR.jar;c:/pantry/derbyLocale_zh_CN.jar;c:/pantry/derbyLocale_zh_TW.jar;c:/pan try/derbynet.jar;c:/pantry/derbyTesting.jar;c:/pantry/derbytools.jar;c:/pantry/f unctionTests.jar;c:/pantry/maps.jar;c:/pantry/tours.jar;.;c:/pantry/junit.jar;c: /pantry/jakarta-oro-2.0.8.jar OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: mkutty Java user home: C:\Documents and Settings\Administrator Java user dir: C:\pantry java.specification.name: Java Platform API Specification java.specification.version: 1.5 - Derby Information JRE - JDBC: J2SE 5.0 - JDBC 3.0 [C:\pantry\derby.jar] 10.3.0.0 alpha - (542712) [C:\pantry\derbytools.jar] 10.3.0.0 alpha - (542712) [C:\pantry\derbynet.jar] 10.3.0.0 alpha - (542712) [C:\pantry\derbyclient.jar] 10.3.0.0 alpha - (542712) Reporter: Manjula Kutty I started the server as follows java org.apache.derby.drda.NetworkServerControl start -p 1527 -h 0.0.0 -noSecurityManager and on the client side though ij ran the following commands ijconnect 'jdbc:derby://mkutty-ibm-lt3:1527/ipv6db;create=true'; --You have to give the host name. the use of local host didn't reproduce this problem ijcreate table tab1(col1 bigint,col2 blob,col3 char, col4 char for bit data,col5 clob, col6 date, col7 decimal, col8 double, col9 double precision, col10 float, col11 integer,col12 long varchar, col13 long varchar for bit data, col14 numeric, col15 real, col16 smallint, col17 time, col18 timestamp, col19 varchar, col20 varchar(3214) for bit data); run the sql with syntax error for n number of times. I got the error in 2 and 3 and 9 try. Then got the following error ERROR 58009: A communications error has been detected: Connection reset by peer: socket write error Then ij lost the connection. Note: It may be little difficult to reproduce the problem, but I could reproduce it more than 4 times. But not always. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2747) Reply incorrectly handles read() returning -1
[ https://issues.apache.org/jira/browse/DERBY-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611312#action_12611312 ] Kurt Huwig commented on DERBY-2747: --- I just signed the ICLA and will fax it tomorrow. Reply incorrectly handles read() returning -1 - Key: DERBY-2747 URL: https://issues.apache.org/jira/browse/DERBY-2747 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.2.2.0 Reporter: Kurt Huwig Priority: Minor Attachments: patch-2747-1.diff, patch-2747-2.diff If java/client/org/apache/derby/client/net/Reply.java encounters a EOF, i.e. reads -1 then it adds this value to the number of bytes read and prints an error message which reads -1 bytes read. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2498) NullPointerException on ClientDataSource.getConnection() when ds.setdatabaseName was invalid
[ https://issues.apache.org/jira/browse/DERBY-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2498: -- Derby Categories: [Newcomer] NullPointerException on ClientDataSource.getConnection() when ds.setdatabaseName was invalid - Key: DERBY-2498 URL: https://issues.apache.org/jira/browse/DERBY-2498 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.3.1.4 Reporter: Myrna van Lunteren The following code snippet: ClientDataSource ds = (ClientDataSource)JDBCDataSource.getDataSource(); // invalid database string ds.setDatabaseName(jdbc:derby:wombat); ds.getConnection(); results (with jdk14) in this stack trace: java.lang.NullPointerException at org.apache.derby.client.am.ProductLevel.init(ProductLevel.java:41) at org.apache.derby.client.net.NetDatabaseMetaData.init(NetDatabaseMetaData.java:40) at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetDatabaseMetaData(ClientJDBCObjectFactoryImpl.java:276) at org.apache.derby.client.net.NetConnection.newDatabaseMetaData_(NetConnection.java:1144) at org.apache.derby.client.am.Connection.completeConnect(Connection.java:1803) at org.apache.derby.client.net.NetConnection.completeConnect(NetConnection.java:412) at org.apache.derby.client.net.NetConnection.initialize(NetConnection.java:297) at org.apache.derby.client.net.NetConnection.init(NetConnection.java:231) at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetConnection(ClientJDBCObjectFactoryImpl.java:213) at org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:186) at org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:163) at org.apache.derbyTesting.functionTests.tests.jdbcapi.DataSourceTest.testJira95ds(DataSourceTest.java:808) This is a similar situation as described for EmbeddedDataSource in DERBY-95. This bug was found when converting the test for DERBY-95 to junit - the old test was explicitly creating an EmbeddedDataSource, so, this was never tested for Client (even when running with network server). Note, that the similar test for XADataSource, even for client, does not result in an NPE. I have not tested PooledDataSource, but it should be checked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2354) Unable to perform select query using DISTINCT on a read-only database
[ https://issues.apache.org/jira/browse/DERBY-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611322#action_12611322 ] Kathey Marsden commented on DERBY-2354: --- Do you have this problem if you set derby.storage.tempDirectory per http://db.apache.org/derby/docs/dev/devguide/tdevdeploy26887.html ? Unable to perform select query using DISTINCT on a read-only database - Key: DERBY-2354 URL: https://issues.apache.org/jira/browse/DERBY-2354 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.2.2.0 Environment: Reproduced in WinXP professional, Linux (Ubuntu 6.10) with Sun Java 5.0 Reporter: Thomas Kelder Attachments: DerbyTest.java It is not possible to perform queries using DISTINCT on a read-only database packaged in a zip file. This generates the following error: ERROR 40XD1: Container was opened in read-only mode. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseContainer.use(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseContainerHandle.useContainer(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.addContainer(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.addContainer(Unknown Source) at org.apache.derby.impl.store.access.heap.Heap.create(Unknown Source) at org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.createConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.createConglomerate(Unknown Source) at org.apache.derby.iapi.store.access.DiskHashtable.init(Unknown Source) at org.apache.derby.iapi.store.access.BackingStoreHashtable.spillToDisk(Unknown Source) at org.apache.derby.iapi.store.access.BackingStoreHashtable.add_row_to_hash_table(Unknown Source) at org.apache.derby.iapi.store.access.BackingStoreHashtable.put(Unknown Source) at org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(Unknown Source) at org.apache.derby.impl.store.access.btree.BTreeScan.fetchSet(Unknown Source) at org.apache.derby.impl.store.access.BackingStoreHashTableFromScan.init(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.createBackingStoreHashtableFromScan(Unknown Source) at org.apache.derby.impl.sql.execute.HashScanResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(Unknown Source) at DerbyTest.main(DerbyTest.java:29) The problem can be reproduced using the attached java program and the following database file: http://ftp2.bigcat.unimaas.nl/~thomas.kelder/derbytest/testdb.zip. Both the 'derby.storage.tempDirectory' and 'derby.stream.error.file' properties are set to writable locations, as advised in the help file. Also see derby-user mailing list thread: http://article.gmane.org/gmane.comp.apache.db.derby.user/6123 This appears to be a bug, possibly a regression. When I converted your DB to10.0 everything worked fine even when I did NOT set the properties for tempDirectory and error.file (hmmm..). When I switched to using the 10.1 or 10.2 jars and accessed the very same database the 40XD1 ERROR happened. (Stanley Bradbury) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2353) intermittent NPEs during DELETE ops in a reasonably large transaction
[ https://issues.apache.org/jira/browse/DERBY-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-2353. --- Resolution: Cannot Reproduce No response since inquiry in Feb 2008. Closing CNR. This can be reopened if it is still an issue. intermittent NPEs during DELETE ops in a reasonably large transaction - Key: DERBY-2353 URL: https://issues.apache.org/jira/browse/DERBY-2353 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.2.2.0 Environment: Seen on both Windows XP and Mac OS X 10.4 Reporter: Dan Karp I'm intermittently seeing NPEs thrown while using the embedded driver to rewrite several rows in a single transaction. Here's the set of commands that were executed on the transaction; the last one is the one that failed: SELECT entry_id FROM zimbra.directory WHERE UPPER(zimbra_id) = '0F850D84-7096-4534-9389-9D85AFC17E8A' AND entry_type = 'acct' DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) = 'ZIMBRACONTACTMAXNUMENTRIES' INSERT INTO zimbra.directory_attrs (entry_id, name, value) VALUES (8, 'zimbraContactMaxNumEntries', '0') DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) = 'ZIMBRAPREFGALAUTOCOMPLETEENABLED' INSERT INTO zimbra.directory_attrs (entry_id, name, value) VALUES (8, 'zimbraPrefGalAutoCompleteEnabled', 'FALSE') DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) = 'ZIMBRAPREFMAILPOLLINGINTERVAL' INSERT INTO zimbra.directory_attrs (entry_id, name, value) VALUES (8, 'zimbraPrefMailPollingInterval', '5m') DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) = 'ZIMBRAPREFGROUPMAILBY' INSERT INTO zimbra.directory_attrs (entry_id, name, value) VALUES (8, 'zimbraPrefGroupMailBy', 'conversation') DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) = 'ZIMBRAFEATUREVIEWINHTMLENABLED' INSERT INTO zimbra.directory_attrs (entry_id, name, value) VALUES (8, 'zimbraFeatureViewInHtmlEnabled', 'TRUE') DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) = 'ZIMBRAPREFMESSAGEVIEWHTMLPREFERRED' INSERT INTO zimbra.directory_attrs (entry_id, name, value) VALUES (8, 'zimbraPrefMessageViewHtmlPreferred', 'TRUE') DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) = 'ZIMBRAPREFREADINGPANEENABLED' INSERT INTO zimbra.directory_attrs (entry_id, name, value) VALUES (8, 'zimbraPrefReadingPaneEnabled', 'TRUE') DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) = 'ZIMBRAFEATUREGALAUTOCOMPLETEENABLED' INSERT INTO zimbra.directory_attrs (entry_id, name, value) VALUES (8, 'zimbraFeatureGalAutoCompleteEnabled', 'TRUE') DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) = 'ZIMBRAPREFCALENDARUSEQUICKADD' Here's the stack trace: Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:89) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:100) at org.apache.derby.impl.jdbc.Util.javaException(Util.java:219) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:386) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:345) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1378) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1272) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1635) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:299) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:233) at com.zimbra.cs.db.DebugPreparedStatement.executeUpdate(DebugPreparedStatement.java:154) And here's the schema: CREATE TABLE directory ( entry_idINTEGER NOT NULL GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, entry_type CHAR(4) NOT NULL, entry_name VARCHAR(128) NOT NULL, zimbra_id CHAR(36), modifiedSMALLINT NOT NULL ); CREATE UNIQUE INDEX i_directory_zimbra_id ON directory(zimbra_id); CREATE UNIQUE INDEX i_directory_entry_type_name ON directory(entry_type, entry_name); CREATE TABLE directory_attrs ( entry_idINTEGER NOT NULL, nameVARCHAR(255) NOT NULL, value VARCHAR(10240) NOT
[jira] Updated: (DERBY-2017) Client driver can insert and commit partial data when a LOB stream throws IOException or does not match the specified length
[ https://issues.apache.org/jira/browse/DERBY-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2017: -- Derby Categories: [High Value Fix, Wrong query result] Client driver can insert and commit partial data when a LOB stream throws IOException or does not match the specified length Key: DERBY-2017 URL: https://issues.apache.org/jira/browse/DERBY-2017 Project: Derby Issue Type: Bug Components: JDBC, Network Client Affects Versions: 10.2.1.6 Reporter: Knut Anders Hatlen Attachments: derby2017_try1.diff, Derby_2017_v1.diff, Derby_2017_v1.stat, StreamErrRepro.java When a LOB stream throws an exception or does not match the specified length, the client driver does not raise an exception until it has finished executing the statement. Therefore, the statement will be executed (and possibly committed) on the server even though the client reports that the statement failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1963) Routine parameter names displayed by dblook are not escaped.
[ https://issues.apache.org/jira/browse/DERBY-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-1963: -- Derby Categories: [Newcomer] Routine parameter names displayed by dblook are not escaped. Key: DERBY-1963 URL: https://issues.apache.org/jira/browse/DERBY-1963 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.3.1.4 Reporter: Daniel John Debrunner Priority: Minor After using this SQL to create a function with a delimited parameter name CREATE FUNCTION FRED (paramOne INTEGER) RETURNS INTEGER LANGUAGE JAVA PARAMETER STYLE JAVA EXTERNAL NAME 'fred.foo' dblook will output a CREATE FUNCTION statement with the parameter name without quotes: CREATE FUNCTION APP.FRED (paramOne INTEGER) RETURNS INTEGER LANGUAGE JAVA PARAMETER STYLE JAVA READS SQL DATA CALLED ON NULL INPUT EXTERNAL NAME 'fred.foo'; Using the output from dblook to re-create the function will result in a function with a different parameter name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1905) Optimizer cost estimates for subqueries are way (way) too high.
[ https://issues.apache.org/jira/browse/DERBY-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-1905: -- Derby Categories: [High Value Fix] Optimizer cost estimates for subqueries are way (way) too high. --- Key: DERBY-1905 URL: https://issues.apache.org/jira/browse/DERBY-1905 Project: Derby Issue Type: Bug Components: Performance, SQL Affects Versions: 10.1.3.2, 10.2.1.6, 10.3.1.4 Reporter: A B Attachments: d1905.sql, d1905_sandbox_doNOTCommit.patch If I run the attached repro (pulled from DERBY-1866) with derby.optimizer.noTimeout=true (meaning the optimizer should take all the time it needs to try out all possible plans within the restrictions of the optimizer overrides), the estimated cost shown in derby.log (if I log the query plan) is over 600k and the estimated row count is over 520k. If, as the code in OptimizerImpl seems to expect, the unit for a cost estimate is milliseconds, then the optimize here is guessing that the query will take over 10 minutes to execute and will return a half-million rows. But in truth the *combined* time for compilation AND execution is just a couple of seconds, and only 15 rows are returned. That suggests to me a rather serious problem with the optimizer cost estimates for subqueries. Among other things this can have a major impact on the optimizer's timeout mechanism for very deeply-nested queries. The optimizer will continue to try out different combinations of indexes/joinOrders/joinStrategies until it either exhausts them all or until the number of milliseconds spent optimizing is greater than the best cost estimate so far. In the case of the repro for this issue, the optimizer quickly exhausts all of the options and so it finishes in a fair amount of time. But in larger queries where there are far more combinations to try (see esp. queries attached to DERBY-1205, DERBY-1777), these severly inflated cost estimates get very large very quickly (sometimes even reaching infinity--see DERBY-1259, DERBY-1260) and so the optimizer just keeps on optimizing and never times out. The result is that for queries like those in DERBY-1777, the optimizer can spend literally hours optimizing a query which then executes in a matter of seconds. I'm still investigating this, but preliminary examination suggests that part of the problem is in some way related to the treatment of outer costs by the optimizer--and in particular, it looks like the optimizer is perhaps too aggressive in multiplying cost estimates by row counts pulled from outer costs. That's just my first guess at the problem, though; there could of course be far more to it than that... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3731) Improve calculation of refSize in ClassSize.java
[ https://issues.apache.org/jira/browse/DERBY-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611342#action_12611342 ] Kathey Marsden commented on DERBY-3731: --- ported fix to do gc before memory estimation to 10.4 and 10.3. Leaving the issue open for possible other improvements. Improve calculation of refSize in ClassSize.java - Key: DERBY-3731 URL: https://issues.apache.org/jira/browse/DERBY-3731 Project: Derby Issue Type: Bug Components: SQL Reporter: Kathey Marsden Priority: Minor Attachments: DERBY-3731_diff.txt java/engine/org/apache/derby/iapi/services/cache/ClassSize.java has a static code block which calculates the size of a reference for the architecture. This code could be improved by adding garbage collection before measuring memory, to give a consistent reading. Also there have been suggestions that we use os.arch or sun.arch.data.model to make the measurement more reliable, especially on 64bit machines. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1902) Intermittent failures in predicatePushdown.sql
[ https://issues.apache.org/jira/browse/DERBY-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611344#action_12611344 ] Kathey Marsden commented on DERBY-1902: --- This may be fixed with the addition of gc() to the reference size calculation, DERBY-3731. We should monitor and see if it comes up again soon. If not perhaps this issue can be closed. Intermittent failures in predicatePushdown.sql -- Key: DERBY-1902 URL: https://issues.apache.org/jira/browse/DERBY-1902 Project: Derby Issue Type: Bug Components: Regression Test Failure, SQL, Test Affects Versions: 10.3.1.4 Environment: Seen on both Solaris 10 and Linux on 2-CPU Opteron boxes, disk cache off Reporter: Øystein Grøvlen Attachments: derbylang.zip For the last week, there have been intermittent failures in the night test in lang/predicatePushdown.sql. There is a plan diff which starts as follows: * Diff file derbyall/derbylang/predicatePushdown.diff *** Start: predicatePushdown jdk1.5.0_07 derbyall:derbylang 2006-09-29 00:39:36 *** 4593 del Hash Join ResultSet: 4593a4593 Nested Loop Join ResultSet: I did not find any changes that seem relevant before the first failing night test. This test has not failed in the tinderbox test which runs on a computer with the disk cache on. For both computers where the failure is seen, the disk cache has been turned off. Hence, it may be that another plan is picked because of slower I/O. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1831) After a database shutdown, Network Server should invalidate all active connections and an appropriate error message should be thrown at the client while using those connec
[ https://issues.apache.org/jira/browse/DERBY-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-1831: -- Derby Categories: [High Value Fix] After a database shutdown, Network Server should invalidate all active connections and an appropriate error message should be thrown at the client while using those connections later. --- Key: DERBY-1831 URL: https://issues.apache.org/jira/browse/DERBY-1831 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1 Environment: Any Reporter: Rajesh Kartha Any connections currently open during the shutdown should be invalidated. This would indicate the correct info - that there are no open connections during the 'show connections' command and the subsequent 'set connection' and sql should fail with appropriate errors. It works as expected in embedded mode, but it is more important to behave accordingly in the case of Network Server where multiple users are connected, rather than throw an obscure error of ERROR 58009: A network protocol error was encountered and the connection . implementation-specific condition for which there was no architected message ij version 10.2 ij connect 'jdbc:derby://localhost:1527/testdb;create=true' as connA; ij drop table t; 0 rows inserted/updated/deleted ij create table t (id int); 0 rows inserted/updated/deleted ij insert into t values (1); 1 row inserted/updated/deleted ij insert into t values (2); 1 row inserted/updated/deleted ij select * from t; ID --- 1 2 2 rows selected -- --Connection A is still open -- ij connect 'jdbc:derby://localhost:1527/testdb' as connB; ij(CONNB) insert into t values (3); 1 row inserted/updated/deleted ij(CONNB) select * from t; ID --- 1 2 3 3 rows selected -- -- Should error out saying there are open connections to the database -- ij(CONNB) connect 'jdbc:derby://localhost:1527/testdb;shutdown=true'; ERROR 08006: DERBY SQL error: SQLCODE: -1, SQLSTATE: 08006, SQLERRMC: Database 'testdb' shutdown. ij(CONNB) disconnect; -- --Connection A is still open -- ij show connections; CONNA - jdbc:derby://localhost:1527/testdb;create=true No current connection -- --Set connection to connection A -- ij set connection connA; -- --Try a sql -- ij select * from t; ERROR 58009: A network protocol error was encountered and the connection has been terminated: the requested command encountered an unarchitected and implementation-specific condition for which there was no architected message ij In embedded the ''shutdown=true' closes all active connections to the database. ij(CONNB) connect 'jdbc:derby:testdb;shutdown=true'; ERROR 08006: Database 'testdb' shutdown. ij(CONNB) disconnect; -- -- Shows no current connections after a shutdown -- ij show connections; No current connection ij set connection connA; IJ ERROR: No connection exists with the name CONNA ij select * from t; IJ ERROR: Unable to establish connection ij Furthermore a related issue DERBY-1737 - need to check for existing connections before shutdown is marked as an improvement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1599) Clob.getSubString() throws NullPointerException when created by updatable result set
[ https://issues.apache.org/jira/browse/DERBY-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-1599: -- Derby Categories: [High Value Fix] Clob.getSubString() throws NullPointerException when created by updatable result set Key: DERBY-1599 URL: https://issues.apache.org/jira/browse/DERBY-1599 Project: Derby Issue Type: Bug Components: JDBC, Network Client Affects Versions: 10.1.3.1, 10.2.1.6 Reporter: Knut Anders Hatlen Priority: Minor Attachments: Repro.java If you create a clob value with one of the ResultSet.updateXXX methods that take a stream or a reader, and retrieve that value with ResultSet.getClob(), a NullPointerException will be thrown when getSubString() is called on the returned Clob object. This happens with the network client driver, and it has been observed on Derby 10.1.3.1 and trunk. Exception in thread main java.lang.NullPointerException at org.apache.derby.client.am.Clob.getSubStringX(Clob.java:229) at org.apache.derby.client.am.Clob.getSubString(Clob.java:210) at Repro.main(Repro.java:24) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1528) Preparing INSERT INTO table SELECT FROM (...) may cause NullPointerException and subsequent internal errors reported by RawStore module
[ https://issues.apache.org/jira/browse/DERBY-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-1528: -- Derby Categories: [High Value Fix] Preparing INSERT INTO table SELECT FROM (...) may cause NullPointerException and subsequent internal errors reported by RawStore module - Key: DERBY-1528 URL: https://issues.apache.org/jira/browse/DERBY-1528 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1 Reporter: Knut Anders Hatlen Attachments: repro1528_assert.java, repro1528_npe.java When preparing a INSERT INTO table SELECT FROM (...) statement, Derby in some cases throw a NullPointerException or an AssertFailure. This happens when a '?' occurs in a VALUES statement in the from list. If one tries to access the table after the NullPointerException, this exception is thrown: ERROR 40XT0: An internal error was identified by RawStore module. Example: ij create table t (text varchar(20), len int); 0 rows inserted/updated/deleted ij prepare p as 'insert into t select x, length(x) from (values(?)) as v(x)'; ERROR XJ001: Java exception: ': java.lang.NullPointerException'. ij select * from t; ERROR 40XT0: An internal error was identified by RawStore module. Replacing '?' with 'CAST (? AS VARCHAR(20))' fixes the problem, but there is enough information in the query to determine the type of the parameter even without the cast. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1433) Client driver does not handle string literals containing where current of correctly
[ https://issues.apache.org/jira/browse/DERBY-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-1433: -- Derby Categories: [High Value Fix] Client driver does not handle string literals containing where current of correctly - Key: DERBY-1433 URL: https://issues.apache.org/jira/browse/DERBY-1433 Project: Derby Issue Type: Bug Components: Network Client, SQL Affects Versions: 10.2.1.6 Reporter: Knut Anders Hatlen Attachments: cursor.java If a string literal contains 'where current of something', the client driver tries to substitute 'something' with the corresponding cursor name on the server. This can lead to an exception being raised (no such cursor) or the string literal being modified. See attached repro. The bug is also present in JCC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1482) Update triggers on tables with blob columns stream blobs into memory even when the blobs are not referenced/accessed.
[ https://issues.apache.org/jira/browse/DERBY-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-1482: -- Derby Categories: [High Value Fix] Update triggers on tables with blob columns stream blobs into memory even when the blobs are not referenced/accessed. - Key: DERBY-1482 URL: https://issues.apache.org/jira/browse/DERBY-1482 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.6 Reporter: Daniel John Debrunner Priority: Minor Suppose I have 1) a table t1 with blob data in it, and 2) an UPDATE trigger tr1 defined on that table, where the triggered-SQL-action for tr1 does NOT reference any of the blob columns in the table. [ Note that this is different from DERBY-438 because DERBY-438 deals with triggers that _do_ reference the blob column(s), whereas this issue deals with triggers that do _not_ reference the blob columns--but I think they're related, so I'm creating this as subtask to 438 ]. In such a case, if the trigger is fired, the blob data will be streamed into memory and thus consume JVM heap, even though it (the blob data) is never actually referenced/accessed by the trigger statement. For example, suppose we have the following DDL: create table t1 (id int, status smallint, bl blob(2G)); create table t2 (id int, updated int default 0); create trigger tr1 after update of status on t1 referencing new as n_row for each row mode db2sql update t2 set updated = updated + 1 where t2.id = n_row.id; Then if t1 and t2 both have data and we make a call to: update t1 set status = 3; the trigger tr1 will fire, which will cause the blob column in t1 to be streamed into memory for each row affected by the trigger. The result is that, if the blob data is large, we end up using a lot of JVM memory when we really shouldn't have to (at least, in _theory_ we shouldn't have to...). Ideally, Derby could figure out whether or not the blob column is referenced, and avoid streaming the lob into memory whenever possible (hence this is probably more of an enhancement request than a bug)... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1256) Remove usage of non-portable methods in derby code
[ https://issues.apache.org/jira/browse/DERBY-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-1256: -- Derby Categories: [High Value Fix] Remove usage of non-portable methods in derby code -- Key: DERBY-1256 URL: https://issues.apache.org/jira/browse/DERBY-1256 Project: Derby Issue Type: Bug Components: Network Server, SQL, Store, Test Reporter: Sunitha Kambhampati Remove usage of non portable methods that use native encoding as they could potentially lead to bugs on platforms with different encodings. Replace with code using fixed conversion, or alternative mechanisms. If the call is required its use should be commented as to why it is required. I went through the classes in java.io package in jdk1.4.2 and have come up with a list of methods, constructors in the java.io.* classes that use native encoding and did a java search on eclipse for the code in java/engine, java/testing, java/drda, java/client. 1)ByteArrayOutputStream.toString() testing - DerbyNetNewServer: System.out.println( bos.toString()); server- NetworkServerCtrlInfo.getCLSSysInfo, getNetSysInfo, 2)DataInputStream.readLine() ArrayInputStream - org.apache.derby.iapi.services.io - java/engine readLine() CorruptRandomAccessFile - org.apache.derbyTesting.functionTests.util.corruptio - java/testing readLine() 3)InputStreamReader(InputStream) StatementDuration - org.apache.derby.diag - java/engine - next() ImportReadData - org.apache.derby.impl.load - java/engine - realOpenFile() ErrorLogReader - org.apache.derby.diag - java/engine - next() UCode_CharStream - org.apache.derby.impl.sql.compile - java/engine - ReInit(InputStream, int, int, int) xmlBinding - org.apache.derbyTesting.functionTests.tests.lang - java/testing - insertDocWithDTD(Connection, String, String, String, int) BaseMonitor - org.apache.derby.impl.services.monitor - java/engine - dumpTempWriter(boolean) DbFile - org.apache.derbyTesting.functionTests.util - java/testing - stringFromFile(InputStream) HandleResult - org.apache.derbyTesting.functionTests.harness - java/testing - handleResult(int, InputStream, InputStream, PrintWriter, String) (2 matches) ProcessStreamResult - org.apache.derbyTesting.functionTests.harness - java/testing - run() FileCompare - org.apache.derbyTesting.functionTests.harness - java/testing - doSysDiff(InputStream, String, String, File, PrintWriter) exec(String, File, PrintWriter, String, String, String, int, boolean, boolean, String, String, String) UCode_CharStream(InputStream, int, int, int) insertFiles(Connection, String, String, int) (2 matches) 4) OuputStreamWriter(OutputStream) ExportWriteData - org.apache.derby.impl.load - java/engine openFile() ProcessStreamResult - org.apache.derbyTesting.functionTests.harness - java/testing ProcessStreamResult(InputStream, BufferedOutputStream, String, String) RawStore - org.apache.derby.impl.store.raw - java/engine run() 5) RandomAccessFile.readLine() ArrayInputStream - org.apache.derby.iapi.services.io - java/engine - readLine() CorruptRandomAccessFile - org.apache.derbyTesting.functionTests.util.corruptio - java/testing - readLine() DerbyNetAutoStart - org.apache.derbyTesting.functionTests.tests.derbynet - java/testing - checkLog(RandomAccessFile, String[]) PrintStream and PrintWriter , print methods uses platforms default charset encoding. = There are also non portable methods in String class new String(byte[]) new String(byte[],int,int) String.getBytes(). There are jira entries already for these- DERBY-900, DERBY-901,DERBY-902,DERBY-903. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-1220) intermittant incorrect syntax errors with ij with ibm15 on zOS
[ https://issues.apache.org/jira/browse/DERBY-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-1220. --- Resolution: Invalid Closing invalid, because this was a JVM issue. Fixed with IBM 1.6 SR1, not sure if there is a fixed version with IBM 1.5 intermittant incorrect syntax errors with ij with ibm15 on zOS -- Key: DERBY-1220 URL: https://issues.apache.org/jira/browse/DERBY-1220 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.6 Environment: ibm15 zOS Reporter: Myrna van Lunteren Attachments: derby.log, floatman102.out, floattypess3.sql The following tests fail with unexpected syntax errors that do not occur with ibm14 on zOS: derbylang/derbylang.fail:lang/altertable.sql derbylang/derbylang.fail:lang/floattypes.sql This may still be a test issue, or a jvm issue, further research is needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1191) Some SQLExceptions, for example those generated from BrokeredStatements, do not print to derby.log even when derby.stream.error.logSeverityLevel=0
[
https://issues.apache.org/jira/browse/DERBY-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-1191:
--
Derby Categories: [High Value Fix]
Some SQLExceptions, for example those generated from BrokeredStatements, do
not print to derby.log even when derby.stream.error.logSeverityLevel=0
-
Key: DERBY-1191
URL: https://issues.apache.org/jira/browse/DERBY-1191
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.1.3.1, 10.2.1.6
Reporter: Kathey Marsden
Priority: Minor
I found this when working on DERBY-1047. Exceptions thrown using
org.apache.derby.impl.jdbc.Util.generateCsSQLException()
do not print to derby.log even when derby.stream.error.logSeverityLevel=0
For example the attached repro generates an expected exception but does not
print the error to the log.
java -Dderby.stream.error.logSeverityLevel=0 Derby1047
This causes an expected exception to be thrown but it does not print to the
derby.log
10.2.0.0 alpha
Apache Derby
Apache Derby Embedded JDBC Driver
done creating table
COL1
---
1
2
PASS: Expected Exception can'tholdable cusror in global xact:Cannot set
holdability ResultSet.HOLD_CURSORS_OVER_COMMIT for a global transaction.
COL1
---
1
2
3
The code generating the exception is in
org.apache.derby.iapi.jdbc.BrokeredStatement
final void checkHoldability() throws SQLException {
int holdability =
controlCheck().checkHoldCursors(resultSetHoldability);
if (holdability != resultSetHoldability)
throw Util.generateCsSQLException(SQLState.CANNOT_HOLD_CURSOR_XA);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1107) For existing databases JDBC metadata queries do not get updated properly between maintenance versions.
[ https://issues.apache.org/jira/browse/DERBY-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-1107: -- Derby Categories: [High Value Fix] For existing databases JDBC metadata queries do not get updated properly between maintenance versions. --- Key: DERBY-1107 URL: https://issues.apache.org/jira/browse/DERBY-1107 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6 Reporter: Kathey Marsden Attachments: derby-1107-proposal1.diff The JDBC DatabaseMetaData queries are stored as stored prepared statements in the database. If a bug is fixed for any of the metadata calls it can require that these queries be changed. Currently existing databases will not get updated properly if a bug is fixed. Ideally the metadata queries should match the derby version that is running. That way we avoid situations where the query is not compatible with the Derby version running. To confirm I : 1) created a database with 10.1.1.0 2) Made a metadata change in my 10.1.2.4 client. 3) Connected to the 10.1.1.0 database with 10.1.2.4 and saw that there was no change to the stored prepared statements in SYS.SYSSTATEMENTS I also confirmed that a database created with 10.1.2.4 does not get changed when reverting to 10.1.1.0. Below this line is some history and reference that might be helful to someone fixing this issue: In discussing DERBY-970, the subject of the metadata stored prepared statements came up. The general questions are: 1) Why do we use stored prepared statements for metadata queries? 2) What issues might there be related to upgrade/downgrade with the metadata stored prepared statements? 3) How do we address potential upgrade/downgrade issues? GENERAL HISTORY: - Cloudscape 5.x had stored prepared statements, a way to store precompiled statements in the database. This is no longer exposed externally. - Metadata stored prepared statements were a performance optimization that predated the statement cache. - In the past, this performance optimization has been of particular importance to gui database browsers that execute all the metadata methods on connection to the database. This would still probably be an issue with embedded even with the statement cache. - All stored prepared statements get recompiled on the first connection to the database if the version changes. UPGRADE HISTORY - In Cloudscape 5.1, the metadata stored prepared statements have traditionally been a source of trouble for even minor version changes as queries change or they refer to methods/stored procedures that may or may not exist in the target version and cannot recompile or execute. - The solution to the problem in Cloudscape v5.1.60 was to automatically always call DD_Version.dropJDBCMetadataSPSes() whenever the version changed up or down in upgradeIfNeeded(). - The workaround before this change to do this automatically was to call this method manually: |CALL Factory.getDatabaseOfConnection(). dropAllJDBCMetaDataSPSes()| HOW DERBY WORKS TODAY: - In Derby we now only call dropJDBCMetadataSPSes() on fullUpgrade and it has been this way since contribution. - I think the problems of upgrade/downgrade for metadata stored prepared statements may exist in Derby. - I don't know a workaround to drop the metadata stored prepared statements if we need to deliver a bug fix or how the ugprade/downgrade is handled currently. - I seem to recall some special handling in Derby for soft upgrade for optimizer directives, but don't know the details. RECENT DISCUSSIONS: In discussing DERBY-970, the subject of the metadata stored prepared statements came up. The general questions are: 1) Why do we use stored prepared statements for metadata queries? 2) What issues might there be related to upgrade/downgrade with the metadata stored prepared statements? 3) How do we address potential upgrade/downgrade issues? MY QUESTIONS Anyone know when/why the dropJDBCMetadataSPSes() on all version changes was removed between Cloudcape 5.1.60 and contribution? How do we deliver bug fixes for metadata queries or handle changes in the metadata queries in Derby? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-728) Unable to create databases whose name containg Chinese characters through the client driver
[
https://issues.apache.org/jira/browse/DERBY-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-728:
-
Derby Categories: [High Value Fix]
Unable to create databases whose name containg Chinese characters through the
client driver
---
Key: DERBY-728
URL: https://issues.apache.org/jira/browse/DERBY-728
Project: Derby
Issue Type: Bug
Components: Network Client
Affects Versions: 10.1.2.1
Environment: Debian unstable, LInux 2.6.14.2, libc 2.3.5-6
Reporter: Andrei Badea
Trying to create a database with the following URL (note the Chinese
character in the database name):
jdbc:derby://localhost:1527/\u4e10;create=true
throws the following exception:
-%-
Exception in thread main org.apache.derby.client.am.SqlException: Unicode
string can't convert to Ebcdic string
at
org.apache.derby.client.net.EbcdicCcsidManager.convertFromUCS2(Unknown Source)
at
org.apache.derby.client.net.Request.writeScalarPaddedString(Unknown Source)
at
org.apache.derby.client.net.NetConnectionRequest.buildRDBNAM(Unknown Source)
at
org.apache.derby.client.net.NetConnectionRequest.buildACCSEC(Unknown Source)
at
org.apache.derby.client.net.NetConnectionRequest.writeAccessSecurity(Unknown
Source)
at
org.apache.derby.client.net.NetConnection.writeServerAttributesAndKeyExchange(Unknown
Source)
at
org.apache.derby.client.net.NetConnection.flowServerAttributesAndKeyExchange(Unknown
Source)
at
org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(Unknown Source)
at org.apache.derby.client.net.NetConnection.flowConnect(Unknown
Source)
at org.apache.derby.client.net.NetConnection.init(Unknown Source)
at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:525)
at java.sql.DriverManager.getConnection(DriverManager.java:193)
at jdbctest.Main.main(Main.java:33)
-%-
It's possible, however, to create databases using the embedded driver, using
an URL like:
jdbc:derby:\u4e10;create=true
Tested with both 10.1.1.0 and 10.1.2.1 with the same result.
Complete code to reproduce the bug:
-%-
public static void main(String[] args) throws Exception {
Class.forName(org.apache.derby.jdbc.ClientDriver);
Connection conn =
DriverManager.getConnection(jdbc:derby://localhost:1527/\u4e10;create=true);
}
-%-
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-723) Escaped JDBC/ODBCC function CHAR(n) incorrect maps to Derby's builtin CHAR() function.
[
https://issues.apache.org/jira/browse/DERBY-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-723:
-
Derby Categories: [High Value Fix]
Escaped JDBC/ODBCC function CHAR(n) incorrect maps to Derby's builtin CHAR()
function.
--
Key: DERBY-723
URL: https://issues.apache.org/jira/browse/DERBY-723
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.0.2.0, 10.1.2.1
Reporter: Daniel John Debrunner
Priority: Minor
JDBC/ODBC define {fn CHAR(n)} as returning a string corresponding to the
ASCII character with codepoint N.
With Derby, {fn CHAR(n)} maps to CHAR(n) which results in the value n
converted to a string.
Most likely would be fixed by DERBY-591, but called out as a special case
beacuse this is a valid escaped function returning the wrong information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-700: - Derby Info: [Existing Application Impact, Release Note Needed] (was: [Release Note Needed, Existing Application Impact]) Derby Categories: [High Value Fix] Derby does not prevent dual boot of database from different classloaders on Linux - Key: DERBY-700 URL: https://issues.apache.org/jira/browse/DERBY-700 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.4.1.3 Environment: ava -version java version 1.4.2_08 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) Reporter: Kathey Marsden Priority: Critical Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, derby-700_06_19_2007, derby-700_diff.txt, derby-700_stat.txt, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat, derby-700_with_NPE_fix_diff.txt, derby-700_with_NPE_fix_stat.txt, derby.log, derby700_singleproperty_v1.diff, derby700_singleproperty_v1.stat, DualBootRepro.java, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html Derby does not prevent dual boot from two different classloaders on Linux. To reproduce run the program DualBootRepro with no derby jars in your classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can change the location by changing the DERBY_LIB_DIR variable. On Linux the output is: $java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] FAIL: Booted database in 2nd loader [EMAIL PROTECTED] On Windows I get the expected output. $ java -cp . DualBootRepro Loading derby from file:10.1.2.1/derby.jar 10.1.2.1/derby.jar Booted database in loader [EMAIL PROTECTED] PASS: Expected exception for dualboot:Another instance of Derby may have already booted the database D:\marsden\repro\dualboot\mydb. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-550) BLOB : java.lang.OutOfMemoryError with network JDBC driver (org.apache.derby.jdbc.ClientDriver)
[
https://issues.apache.org/jira/browse/DERBY-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611350#action_12611350
]
Kathey Marsden commented on DERBY-550:
--
I wonder if this issue can be closed now that the repro passes without error
according to Tomohito
BLOB : java.lang.OutOfMemoryError with network JDBC driver
(org.apache.derby.jdbc.ClientDriver)
---
Key: DERBY-550
URL: https://issues.apache.org/jira/browse/DERBY-550
Project: Derby
Issue Type: Bug
Components: JDBC, Network Server
Affects Versions: 10.1.1.0
Environment: Any environment.
Reporter: Grégoire Dubois
Assignee: Tomohito Nakayama
Attachments: BlobOutOfMem.java
Using the org.apache.derby.jdbc.ClientDriver driver to access the
Derby database through network, the driver is writting all the file into
memory (RAM) before sending
it to the database.
Writting small files (smaller than 5Mo) into the database works fine,
but it is impossible to write big files (40Mo for example, or more), without
getting the
exception java.lang.OutOfMemoryError.
The org.apache.derby.jdbc.EmbeddedDriver doesn't have this problem.
Here follows some code that creates a database, a table, and trys to write a
BLOB. 2 parameters are to be changed for the code to work for you :
DERBY_DBMS_PATH and FILE
import NetNoLedge.Configuration.Configs;
import org.apache.derby.drda.NetworkServerControl;
import java.net.InetAddress;
import java.io.*;
import java.sql.*;
/**
*
* @author greg
*/
public class DerbyServer_JDBC_BLOB_test {
// The unique instance of DerbyServer in the application.
private static DerbyServer_JDBC_BLOB_test derbyServer;
private NetworkServerControl server;
private static final String DERBY_JDBC_DRIVER =
org.apache.derby.jdbc.ClientDriver;
private static final String DERBY_DATABASE_NAME = Test;
// ###
// ### SET HERE THE EXISTING PATH YOU WANT
// ###
private static final String DERBY_DBMS_PATH = /home/greg/DatabaseTest;
// ###
// ###
private static int derbyPort = 9157;
private static String userName = user;
private static String userPassword = password;
//
###
// # DEFINE HERE THE PATH TO THE FILE YOU WANT TO WRITE INTO
THE DATABASE ###
// # TRY A 100kb-3Mb FILE, AND AFTER A 40Mb OR BIGGER FILE
#
//
###
private static final File FILE = new File(/home/greg/01.jpg);
//
###
//
###
/**
* pUsed to test the server.
*/
public static void main(String args[]) {
try {
DerbyServer_JDBC_BLOB_test.launchServer();
DerbyServer_JDBC_BLOB_test server = getUniqueInstance();
server.start();
System.out.println(Server started);
// After the server has been started, launch a first connection
to the database to
// 1) Create the database if it doesn't exist already,
// 2) Create the tables if they don't exist already.
Class.forName(DERBY_JDBC_DRIVER).newInstance();
Connection connection = DriverManager.getConnection
(jdbc:derby://localhost:+derbyPort+/+DERBY_DATABASE_NAME+;create=true,
userName, userPassword);
System.out.println(Network JDBC connection to Derby succeded.
Database created if not created already.);
Statement statement =
connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
Statement statement2;
// Create the table file if it doesn't already exist.
String [] tableNames={file};
boolean exist;
String currentTable;
ResultSet result = statement.executeQuery(SELECT TABLENAME FROM
SYS.SYSTABLES);
for (int i=0;itableNames.length;i++) {
exist=false;
while (result.next()){
if (tableNames[i].equalsIgnoreCase(result.getString(1)))
[jira] Assigned: (DERBY-2905) Shutting down embedded Derby does not remove all code, the AutoloadDriver is left registered in the DriverManager.
[ https://issues.apache.org/jira/browse/DERBY-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramin Moazeni reassigned DERBY-2905: Assignee: (was: Ramin Moazeni) Shutting down embedded Derby does not remove all code, the AutoloadDriver is left registered in the DriverManager. -- Key: DERBY-2905 URL: https://issues.apache.org/jira/browse/DERBY-2905 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.2.2.0, 10.3.1.4, 10.4.1.3 Reporter: Daniel John Debrunner Attachments: DERBY-2905v0.diff, DERBY-2905v0.stat, DERBY-2905v1.diff, DERBY-2905v1.stat, DERBY-2905v3.diff, DERBY-2905v3.stat, Main.java, Mainv1.java After a shutdown of the embedded driver the AutoloadDriver is not unregistered from DriverManager. However it does not support any future loading of connections so it has no value in remaining registered. Since the DriverManager class will remain forever, this means the Derby code will remain forever in the JVM, even if Derby was loaded by a separate class loader. Regression from 10.1 since before the AutoloadedDriver the internal driver did unregister itself from the DriverManager on a shutdown. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-321) ASSERT FAILED invalid space required 10012 newDataToWrite.getUsed() 10012 nextRecordOffset 189 ... on a database recoverty.
[ https://issues.apache.org/jira/browse/DERBY-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-321. -- Resolution: Cannot Reproduce Closing this CNR. If we get a repro or it happens again it can be reopened. ASSERT FAILED invalid space required 10012 newDataToWrite.getUsed() 10012 nextRecordOffset 189 ... on a database recoverty. --- Key: DERBY-321 URL: https://issues.apache.org/jira/browse/DERBY-321 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.1.1.0 Environment: Windows jdk142 Reporter: Suresh Thalamati Priority: Minor while doing random crash/recovery tests. I got the following assert failure: org.apache.derby.iapi.services.sanity.AssertFailure: ASSERT FAILED invalid space required 10012 newDataToWrite.getUsed() 10012 nextRecordOffset 1890 newOffset 1890 reservedSpaceFieldId 5 startField 0 newEndFieldExclusive 8 newFieldCount 8 oldFieldCount 6 slot 3 freeSpace 5439 unusedSpace 0 page Page(454,Container(0, 1152)) 2005-05-24 18:28:45.234 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.1.0.0 alpha - (1): instance c013800d-0104-0ff6-9447-00109d80 on database directory G:\stresstests\csitm Exception trace: org.apache.derby.iapi.services.sanity.AssertFailure: ASSERT FAILED invalid space required 10012 newDataToWrite.getUsed() 10012 nextRecordOffset 1890 newOffset 1890 reservedSpaceFieldId 5 startField 0 newEndFieldExclusive 8 newFieldCount 8 oldFieldCount 6 slot 3 freeSpace 5439 unusedSpace 0 page Page(454,Container(0, 1152)) at org.apache.derby.iapi.services.sanity.SanityManager.THROWASSERT(SanityManager.java:150) at org.apache.derby.impl.store.raw.data.StoredPage.storeRecordForUpdate(StoredPage.java:7449) at org.apache.derby.impl.store.raw.data.StoredPage.storeRecord(StoredPage.java:7098) at org.apache.derby.impl.store.raw.data.UpdateOperation.undoMe(UpdateOperation.java:200) at org.apache.derby.impl.store.raw.data.PhysicalUndoOperation.doMe(PhysicalUndoOperation.java:146) at org.apache.derby.impl.store.raw.log.FileLogger.logAndUndo(FileLogger.java:532) at org.apache.derby.impl.store.raw.xact.Xact.logAndUndo(Xact.java:361) at org.apache.derby.impl.store.raw.log.FileLogger.undo(FileLogger.java:1014) at org.apache.derby.impl.store.raw.xact.Xact.abort(Xact.java:906) at org.apache.derby.impl.store.raw.xact.XactFactory.rollbackAllTransactions(XactFactory.java:498) at org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:1082) at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:323) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1985) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:284) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:539) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:994) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1985) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:284) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:539) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:418) at org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:752) at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:173) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1985) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:284) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1832) at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1698) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1577) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:996) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:988) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:533) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:1548) at org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:193) at
[jira] Updated: (DERBY-3368) Threading issue with DependencyManager may cause in-memory dependencies to be lost.
[
https://issues.apache.org/jira/browse/DERBY-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-3368:
--
Derby Categories: [High Value Fix]
This could potentially result in a corrupt index and wrong results so marking
as a high value fix candidate.
Threading issue with DependencyManager may cause in-memory dependencies to be
lost.
---
Key: DERBY-3368
URL: https://issues.apache.org/jira/browse/DERBY-3368
Project: Derby
Issue Type: Bug
Components: Services
Reporter: Daniel John Debrunner
Priority: Minor
When a thread compiles a language prepared statement P a set of in-memory
Dependency objects is created, e.g. if P accesses table A
Dependency {P depends on A}
When this Dependency is added to the dependency manager if an equivalent one
(same provider and dependent) exists then the duplicate will not be added.
The StatementContext keeps track of these added Dependency so that if the
compilation fails the Dependency will be removed, comparing by the exact same
Dependency object (not by equivalence).
If a thread T1 compiling P fails, then another thread may try to compile P
(same object). If this second thread T2 compiles successfully the following
could happen:
1) T1 compiles P creates Dependency {P depends on A} in dependency manager
2) T1 fails to compile, but does not yet execute its cleanup
3) T2 compiles P successfully, attempts to add Dependency {P depends on A} to
the manager but it is a duplicate so T1's version is left and T2's is not
added.
4) T1 completes its cleanup and removes Dependency {P depends on A}
5) P no longer depends on A
Concern is that the security system GRANT/REVOKE is based upon the dependency
manager as well as correctness for indexes (e.g. this could cause a recompile
to be missed for an INSERT table when an index is added).
For this to actually happen there has to be a situation where one thread
(connection) can compile a statement that another one fails on (and be
compiling at near identical times). I haven't got a reproducible case yet,
but I can get two statements to be compiling the same statement plan (P).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3645) Insert into selecting BLOB column twice leads to SQLException: Restore of a serializable or SQLData object of class error selecting from the table
[ https://issues.apache.org/jira/browse/DERBY-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3645: -- Derby Categories: [Data corruption, High Value Fix] Insert into selecting BLOB column twice leads to SQLException: Restore of a serializable or SQLData object of class error selecting from the table -- Key: DERBY-3645 URL: https://issues.apache.org/jira/browse/DERBY-3645 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.3.0, 10.4.1.4, 10.5.0.0 Reporter: Kathey Marsden Attachments: DoubleInsertInto.java The following code which inserts into a table by selecting a blob column twice from another table, causes SQLException: Restore of a serializable or SQLData object of class error selecting from the table. See attached program DoubleInsertInto for full repro. Stack trace is below. Verified back to 10.3 but probably goes back further. s.executeUpdate(CREATE TABLE T_MAIN( + ID INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, + V BLOB(590473235) )); String ins1 = INSERT INTO T_MAIN(V) VALUES (?); PreparedStatement ps; ps = c.prepareStatement(ins1); byte[] bytes = new byte[35000]; for (int i = 0; i 35000; i++) bytes[i] = (byte) i ; ps.setBytes(1, bytes); ps.executeUpdate(); ps.close(); s.executeUpdate(CREATE TABLE T_COPY ( V1 BLOB(2M), V2 BLOB(2M))); Statement stmt = c.createStatement(); stmt.executeUpdate(INSERT INTO T_COPY SELECT V, V FROM T_MAIN); ResultSet rs = stmt.executeQuery(SELECT * FROM T_COPY); rs.next(); String v1 = rs.getString(1); String v2 = rs.getString(2); System.out.println(v1: + v1); System.out.println(v2: + v2); System.out.println(I am done); Exception in thread main java.sql.SQLException: Restore of a serializable or SQLData object of class , attempted to re ad more data than was originally stored at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:87) at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:223) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:398) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2125) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) at org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(EmbedResultSet.java:4320) at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:463) at org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:367) at DoubleInsertInto.main(DoubleInsertInto.java:47) Caused by: java.sql.SQLException: Restore of a serializable or SQLData object of class , attempted to read more data tha n was originally stored at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:11 9) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) ... 10 more Caused by: java.sql.SQLException: Java exception: ': java.io.EOFException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:11 9) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:87) at org.apache.derby.impl.jdbc.Util.javaException(Util.java:244) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403) ... 8 more Caused by: java.io.EOFException at org.apache.derby.iapi.types.SQLBinary.readBinaryLength(SQLBinary.java:350) at org.apache.derby.iapi.types.SQLBinary.readExternalFromArray(SQLBinary.java:328) at org.apache.derby.impl.store.raw.data.StoredPage.readRecordFromArray(StoredPage.java:5568) at
[jira] Updated: (DERBY-3646) Embedded returns wrong results when selecting a blob column twice and using getBinaryStream()
[ https://issues.apache.org/jira/browse/DERBY-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3646: -- Derby Categories: [High Value Fix, Wrong query result] Embedded returns wrong results when selecting a blob column twice and using getBinaryStream() - Key: DERBY-3646 URL: https://issues.apache.org/jira/browse/DERBY-3646 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.1.3, 10.5.0.0 Reporter: Kathey Marsden Attachments: DoubleSelect.java The attached program DoubleSelect selects a blob column twice and tries to access the blob column with getBinaryStream. With embedded the output is: 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 I am done Two things seem to be happening with embedded. 1) Both getBinaryStream() calls are returning the same stream. 2) The second getBinaryStream() call throws away 4 bytes. With client the output is: Exception in thread main java.io.IOException: The object is already closed. at org.apache.derby.client.am.CloseFilterInputStream.read(CloseFilterInputStream.java:50) at DoubleSelect.printNextTen(DoubleSelect.java:53) at DoubleSelect.main(DoubleSelect.java:43) 0 1 2 3 4 5 6 7 8 9 So with client it looks like the second getBinaryStream() call closes the first stream but then returns the right result for the second stream. Perhaps embedded should behave the same as client or perhaps the query should just work. Regardless embedded should not return wrong results. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3312) Local Network Server Performance degradation with 10.2 or later
[ https://issues.apache.org/jira/browse/DERBY-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3312: -- Derby Categories: [High Value Fix] Local Network Server Performance degradation with 10.2 or later --- Key: DERBY-3312 URL: https://issues.apache.org/jira/browse/DERBY-3312 Project: Derby Issue Type: Bug Components: Network Server, Performance Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1 Environment: Intel x86 based server SuSE Linux Enterprise Server 10 Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Derby 10.3.2.1 Reporter: Timothy Graf Attachments: LobPerf.java We have a Java based XML-RPC client/server product that incorporates an embedded Derby database and network server. Our client uses the derby JDBC ndriver and network client to connect to the Derby Network Server. We recently moved from Cloudscape, which I believe used the 10.1.3.1 Derby code, because of other issues which seem to be resolved by moving to the latest Derby release. We have a very simple database with a simple table. This table does include BLOBs, however its size has not been an issue and we limit our records to 500. Since moving to the latest release of Derby, version 10.3.2.1, we noticed that our clients running on the same machine as our server take much longer to retrieve a list of records from the database. Our clients running on a remote machine do not seem to have any performance issues when retrieving the same list of records. We start our Network Server in Java through the API so I don't think the Security Manager is the issue. I read that performance could be affected by the Security Manager, but according to the Derby documentation, The Network Server will not attempt to install a security manager if you start the server from your application using the programmatic API ... I tried going back several releases of Derby and the performance issue seems to go away when I run with version 10.1.3.1 of Derby. However we see the same issue that we saw with Cloudscape in that we can not turn off connection logging. We also had stability problems with the Network Server with Cloudscape. We would really prefer to use the latest Derby release however the performance issues are a sever limitation. I thought that maybe this was a simple Network Server configuration issue however after researching this issue I have not found anything from a configuration standpoint that may help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-151) Thread termination - XSDG after operation is 'complete'
[ https://issues.apache.org/jira/browse/DERBY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-151: - Derby Categories: [High Value Fix] Thread termination - XSDG after operation is 'complete' Key: DERBY-151 URL: https://issues.apache.org/jira/browse/DERBY-151 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.0.2.1 Environment: Linux kernel 2.4.21-243-athlon (SuSE 9.0) Reporter: Barnet Wagman Attachments: d151.java, derby.log, Derby151Test.java I've encountered what appears to be a bug related to threading. After an INSERT operation, if the invoking thread terminates too quickly, Derby throws an XSDG. The bug is a bit difficult to isolate but it occurs consistently in the following situation (with a particular database and an operation of a particular size): Derby is running in embedded mode with autocommit on. The application performs an INPUT operation from a thread that is not the main thread. The INPUT is issued using a PreparedStatement. The INPUT adds ~ 256 records of six fields each. (Note that INSERTs of this size seem to work fine in other contexts.) The preparedStatement.executeUpdate() seems to excute successfully; at least it returns without throwing an exception. The thread that invoked the INPUT operation then terminates (but NOT the application). The next INPUT operation then results in an ERROR XSDG1: Page Page(7,Container(0, 1344)) could not be written to disk, please check if disk is full. The disk is definitely not full. HOWEVER, if I put the calling thread to sleep for a second before it exits, the problem does not occur. I'm not quite sure what to make of this. I was under the impression that most of Derby's activity occurs in the application's threads. Could Derby be creating a child thread from in the application thread, which dies when the parent thread terminates? Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1017) locking issue with a select statement using an order by clause
[
https://issues.apache.org/jira/browse/DERBY-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-1017:
--
Derby Categories: [High Value Fix]
locking issue with a select statement using an order by clause
--
Key: DERBY-1017
URL: https://issues.apache.org/jira/browse/DERBY-1017
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.0.2.0
Environment: Windows XP Professional operating system and Java2
platform using JDK 5.0
Reporter: Mark H. Kaplan
Attachments: derbyLocking.zip
I am using the network version of Derby (version 10 - the network version). I
am running two threads. The first thread is doing an insert into a table but
not committing. The second table is doing a select statement. When the select
statement has an order by clause, it will not complete but when it does not
have the order by clause, it completes while the first thread is sleeping.
The database contains one table with five columns. I have tried having an
index on the order by column but that does not seem to make a difference. I
have not set any isolation level on the database so it is using the default
of TRANSACTION_READ_COMMITTED.
The insert statement in the first thread looks like:
INSERT INTO Authors (au_id, au_lname, au_fname, phone, contract) VALUES
('999-99-', 'last', 'first', 'xxx-', 0)
The select statement in the second thread looks like:
SELECT au_id, au_lname, au_fname, phone, contract FROM authors where au_lname
= 'xxx' ORDER BY au_fname
MORE INFORMATION --
My order by select statement does timeout with the error 40XL1. I tried
putting an index on the au_fname but that did not make a difference
I have included locking data which I retrieved by running a SELECT * FROM
NEW org.apache.derby.diag.LockTable() AS LT while the second thread was
doing its SELECT statement. I do not understand the data but I thought that
it might give you a better idea of what is going on. I have also included the
database sql script that creates the database table and the two sql
statements that I am running in separate threads to give you a better idea of
what I am doing. Let me know if you need any other information:
(Locking Data)
XID |TYPE |MODE |TAB |LOCK |STATE |TABLETYPE |LOCK |INDEXNAME
===
302 |ROW |X |AUTHORS |(2,18) |GRANT |T |1 |null
302 |ROW |X |AUTHORS |(1,7) |GRANT |T |1 |null
304 |ROW |S |AUTHORS |(1,7) |WAIT |T |0 |null
302 |TABLE |IX |AUTHORS |Tablelock |GRANT |T |3 |null
304 |TABLE |IS |AUTHORS |Tablelock |GRANT |T |1 |null
(SQL Script)
DROP TABLE authors;
CREATE TABLE authors (
au_id VARCHAR(32) NOT NULL,
au_lname VARCHAR(40) ,
au_fname VARCHAR(20) ,
phone VARCHAR(12) ,
contract INT NOT NULL,
PRIMARY KEY (au_id)
);
CREATE INDEX firstnameindex ON authors (au_fname);
(SQL Statements)
Thread 1 - INSERT INTO Authors (au_id, au_lname, au_fname, phone, contract)
VALUES ('999-99-', 'last', 'first', 'xxx-', 0)
Thread2 - SELECT au_id, au_lname, au_fname, phone, contract FROM authors
where au_lname = 'xxx' ORDER BY au_fname
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1261) Two triggers on same table cause ERROR 54038: Maximum depth of nested triggers was exceeded.
[ https://issues.apache.org/jira/browse/DERBY-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-1261: -- Derby Categories: [High Value Fix] Two triggers on same table cause ERROR 54038: Maximum depth of nested triggers was exceeded. -- Key: DERBY-1261 URL: https://issues.apache.org/jira/browse/DERBY-1261 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0 Environment: Embedded on Solaris x86 Reporter: Øystein Grøvlen Two triggers on same table may lead to self-recursion: ij create table t3(i integer primary key, j integer, t timestamp); 0 rows inserted/updated/deleted ij create trigger tr3i after insert on t3 referencing new as new for each row mode db2sql update t3 set t = current_timestamp where i = new.i; 0 rows inserted/updated/deleted ij insert into t3 values (1, 1, NULL); 1 row inserted/updated/deleted ij create trigger tr3u after update on t3 referencing old as old for each row mode db2sql update t3 set t = current_timestamp where i = old.i; 0 rows inserted/updated/deleted ij insert into t3 values (2, 1, NULL); ERROR 54038: Maximum depth of nested triggers was exceeded. ij update t3 set j=j+1; 1 row inserted/updated/deleted ij create trigger tr3u2 after update on t3 referencing old as old for each row mode db2sql update t3 set j = 0 where i = old.i and j 2; 0 rows inserted/updated/deleted ij update t3 set j=j+1; ERROR 54038: Maximum depth of nested triggers was exceeded. From derby.log: 2006-04-27 10:03:54.792 GMT Thread[main,5,main] (XID = 1274), (SESSIONID = 0), (DATABASE = testDB), (DRDAID = null), Cleanup action starting 2006-04-27 10:03:54.792 GMT Thread[main,5,main] (XID = 1274), (SESSIONID = 0), (DATABASE = testDB), (DRDAID = null), Failed Statement is: insert into t3 values (2, 1, NULL) ERROR 54038: Maximum depth of nested triggers was exceeded. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.pushTriggerExecutionContext(GenericLanguageConnectionContext.java:2104) at org.apache.derby.impl.sql.execute.InternalTriggerExecutionContext.init(InternalTriggerExecutionContext.java:179) at org.apache.derby.impl.sql.execute.GenericExecutionFactory.getTriggerExecutionContext(GenericExecutionFactory.java:302) at org.apache.derby.impl.sql.execute.TriggerEventActivator.init(TriggerEventActivator.java:105) at org.apache.derby.impl.sql.execute.UpdateResultSet.fireBeforeTriggers(UpdateResultSet.java:798) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:283) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:361) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(GenericTriggerExecutor.java:169) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(RowTriggerExecutor.java:110) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(TriggerEventActivator.java:277) at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1134) at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:522) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:361) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1161) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:567) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:497) at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:313) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310) at org.apache.derby.impl.tools.ij.Main.go(Main.java:203) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:169) at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55) at org.apache.derby.tools.ij.main(ij.java:60) Cleanup action completed 2006-04-27 10:06:18.589 GMT Thread[main,5,main] (XID = 1293), (SESSIONID = 0), (DATABASE = testDB), (DRDAID = null), Cleanup action starting 2006-04-27 10:06:18.589 GMT Thread[main,5,main] (XID = 1293), (SESSIONID = 0), (DATABASE = testDB), (DRDAID = null), Failed Statement is: update t3 set j=j+1 ERROR 54038: Maximum depth of nested triggers was exceeded. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301) at
[jira] Commented: (DERBY-550) BLOB : java.lang.OutOfMemoryError with network JDBC driver (org.apache.derby.jdbc.ClientDriver)
[
https://issues.apache.org/jira/browse/DERBY-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611367#action_12611367
]
Tomohito Nakayama commented on DERBY-550:
-
My understanding is that performance of memory usage was improved issues
including DERBY-1513, DERBY-1535 and other issues worked at that time
I think this issue should be closed.
BLOB : java.lang.OutOfMemoryError with network JDBC driver
(org.apache.derby.jdbc.ClientDriver)
---
Key: DERBY-550
URL: https://issues.apache.org/jira/browse/DERBY-550
Project: Derby
Issue Type: Bug
Components: JDBC, Network Server
Affects Versions: 10.1.1.0
Environment: Any environment.
Reporter: Grégoire Dubois
Assignee: Tomohito Nakayama
Attachments: BlobOutOfMem.java
Using the org.apache.derby.jdbc.ClientDriver driver to access the
Derby database through network, the driver is writting all the file into
memory (RAM) before sending
it to the database.
Writting small files (smaller than 5Mo) into the database works fine,
but it is impossible to write big files (40Mo for example, or more), without
getting the
exception java.lang.OutOfMemoryError.
The org.apache.derby.jdbc.EmbeddedDriver doesn't have this problem.
Here follows some code that creates a database, a table, and trys to write a
BLOB. 2 parameters are to be changed for the code to work for you :
DERBY_DBMS_PATH and FILE
import NetNoLedge.Configuration.Configs;
import org.apache.derby.drda.NetworkServerControl;
import java.net.InetAddress;
import java.io.*;
import java.sql.*;
/**
*
* @author greg
*/
public class DerbyServer_JDBC_BLOB_test {
// The unique instance of DerbyServer in the application.
private static DerbyServer_JDBC_BLOB_test derbyServer;
private NetworkServerControl server;
private static final String DERBY_JDBC_DRIVER =
org.apache.derby.jdbc.ClientDriver;
private static final String DERBY_DATABASE_NAME = Test;
// ###
// ### SET HERE THE EXISTING PATH YOU WANT
// ###
private static final String DERBY_DBMS_PATH = /home/greg/DatabaseTest;
// ###
// ###
private static int derbyPort = 9157;
private static String userName = user;
private static String userPassword = password;
//
###
// # DEFINE HERE THE PATH TO THE FILE YOU WANT TO WRITE INTO
THE DATABASE ###
// # TRY A 100kb-3Mb FILE, AND AFTER A 40Mb OR BIGGER FILE
#
//
###
private static final File FILE = new File(/home/greg/01.jpg);
//
###
//
###
/**
* pUsed to test the server.
*/
public static void main(String args[]) {
try {
DerbyServer_JDBC_BLOB_test.launchServer();
DerbyServer_JDBC_BLOB_test server = getUniqueInstance();
server.start();
System.out.println(Server started);
// After the server has been started, launch a first connection
to the database to
// 1) Create the database if it doesn't exist already,
// 2) Create the tables if they don't exist already.
Class.forName(DERBY_JDBC_DRIVER).newInstance();
Connection connection = DriverManager.getConnection
(jdbc:derby://localhost:+derbyPort+/+DERBY_DATABASE_NAME+;create=true,
userName, userPassword);
System.out.println(Network JDBC connection to Derby succeded.
Database created if not created already.);
Statement statement =
connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
Statement statement2;
// Create the table file if it doesn't already exist.
String [] tableNames={file};
boolean exist;
String currentTable;
ResultSet result = statement.executeQuery(SELECT TABLENAME FROM
SYS.SYSTABLES);
for (int i=0;itableNames.length;i++) {
exist=false;
while (result.next()){
[jira] Updated: (DERBY-3083) Network server demands a file called derbynet.jar in classpath
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3083: -- Derby Categories: [High Value Fix] Network server demands a file called derbynet.jar in classpath Key: DERBY-3083 URL: https://issues.apache.org/jira/browse/DERBY-3083 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.3.1.4 Reporter: Aaron Digulla Attachments: derby-3083-01-requireDerbynet-aa.diff, derby-3083-01-requireDerbynet-ab.diff, derby-716-10-datatypesCollation-aa.diff The network server will not start if the derbynet jar is added under a different name than derbynet.jar to the classpath. This makes it impossible to use it in maven projects where the jar is renamed to derbynet-10.3.1.4.jar. This did work with 10.2.2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-177) Unnecessary waiting within EmbedDatabaseMetaData.getIndexInfo()
[ https://issues.apache.org/jira/browse/DERBY-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-177: - Derby Categories: [High Value Fix] Unnecessary waiting within EmbedDatabaseMetaData.getIndexInfo() --- Key: DERBY-177 URL: https://issues.apache.org/jira/browse/DERBY-177 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.0.2.2 Environment: Windows XP, JDK 1.4.2_07, derby embedded server Reporter: Jörg von Frantzius Attachments: tablelock.diff, testhang.diff When setting up a new schema (creating tables, constraints and indexes), using a JDO implementation's autocreate feature (JPOX JDO), the application hangs for 20 seconds in a call to EmbedDatabaseMetaData.getIndexInfo(). The stacktrace is: Thread [main] (Suspended) Object.wait(long) line: not available [native method] ActiveLock.waitForGrant(int) line: not available LockSet.lockObject(Object, Lockable, Object, int, Latch) line: not available SinglePool.zeroDurationlockObject(Object, Lockable, Object, int) line: not available RowLockingRR(RowLocking3).zeroDurationLockRecordForWrite(Transaction, RecordHandle, boolean, boolean) line: not available HeapController.lockRow(RecordHandle, int, boolean, int) line: not available HeapController.lockRow(RowLocation, int, boolean, int) line: not available B2IRowLocking3.lockRowOnPage(BTree, LeafControlRow, LeafControlRow, int, boolean, FetchDescriptor, DataValueDescriptor[], RowLocation, int, int) line: not available B2IRowLocking3.lockNonScanPreviousRow(BTree, LeafControlRow, int, FetchDescriptor, DataValueDescriptor[], RowLocation, OpenBTree, int, int) line: not available B2IController(BTreeController).doIns(DataValueDescriptor[]) line: not available B2IController(BTreeController).insert(DataValueDescriptor[]) line: not available B2IController.insert(DataValueDescriptor[]) line: not available TabInfoImpl.insertRowListImpl(RowList, TransactionController, RowLocation[], boolean) line: not available TabInfoImpl.insertRow(ExecRow, TransactionController, boolean) line: not available DataDictionaryImpl.addDescriptorNow(TupleDescriptor, TupleDescriptor, int, boolean, TransactionController, boolean) line: not available DataDictionaryImpl.addSPSParams(SPSDescriptor, TransactionController, boolean) line: not available DataDictionaryImpl.updateSPS(SPSDescriptor, TransactionController, boolean, boolean, boolean, boolean) line: not available SPSDescriptor.updateSYSSTATEMENTS(LanguageConnectionContext, int, TransactionController) line: not available SPSDescriptor.getPreparedStatement(boolean) line: not available SPSDescriptor.getPreparedStatement() line: not available ExecSPSNode.generate(ByteArray) line: not available GenericStatement.prepMinion(LanguageConnectionContext, boolean, Object[], SchemaDescriptor, boolean) line: not available GenericStatement.prepare(LanguageConnectionContext) line: not available GenericLanguageConnectionContext.prepareInternalStatement(String) line: not available EmbedPreparedStatement30(EmbedPreparedStatement).init(EmbedConnection, String, boolean, int, int, int, int, int[], String[]) line: not available EmbedPreparedStatement30(EmbedPreparedStatement20).init(EmbedConnection, String, boolean, int, int, int, int, int[], String[]) line: not available EmbedPreparedStatement30.init(EmbedConnection, String, boolean, int, int, int, int, int[], String[]) line: not available Driver30.newEmbedPreparedStatement(EmbedConnection, String, boolean, int, int, int, int, int[], String[]) line: not available EmbedConnection30(EmbedConnection).prepareMetaDataStatement(String) line: not available EmbedDatabaseMetaData.prepareSPS(String, String) line: not available EmbedDatabaseMetaData.getPreparedQuery(String) line: not available EmbedDatabaseMetaData.getIndexInfo(String, String, String, boolean, boolean) line: not available [## entry into Derby code ##] CloudscapeAdapter(DatabaseAdapter).getExistingIndexes(Connection, DatabaseMetaData, String, String, String) line: 1257 ClassTable(TableImpl).getExistingCandidateKeys(Connection) line: 839 ClassTable(TableImpl).validateCandidateKeys(Connection, boolean) line: 463 ClassTable(TableImpl).validateConstraints(Connection, boolean) line: 293 RDBMSManager$ClassAdder.addClassTablesAndValidate(String[], ClassLoaderResolver) line: 2546 RDBMSManager$ClassAdder.execute(Connection, ClassLoaderResolver) line: 2108
[jira] Updated: (DERBY-2991) Index split deadlock
[ https://issues.apache.org/jira/browse/DERBY-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2991: -- Derby Categories: [High Value Fix] Index split deadlock Key: DERBY-2991 URL: https://issues.apache.org/jira/browse/DERBY-2991 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.2.2.0, 10.3.1.4 Environment: Windows XP, Java 6 Reporter: Bogdan Calmac Attachments: derby.log, InsertSelectDeadlock.java, Repro2991.java, stacktraces_during_deadlock.txt After doing dome research on the mailing list, it appears that the index split deadlock is a known behaviour, so I will start by describing the theoretical problem first and then follow with the details of my test case. If you have concurrent select and insert transactions on the same table, the observed locking behaviour is as follows: - the select transaction acquires an S lock on the root block of the index and then waits for an S lock on some uncommitted row of the insert transaction - the insert transaction acquires X locks on the inserted records and if it needs to do an index split creates a sub-transaction that tries to acquire an X lock on the root block of the index In summary: INDEX LOCK followed by ROW LOCK + ROW LOCK followed by INDEX LOCK = deadlock In the case of my project this is an important issue (lack of concurrency after being forced to use table level locking) and I would like to contribute to the project and fix this issue (if possible). I was wondering if someone that knows the code can give me a few pointers on the implications of this issue: - Is this a limitation of the top-down algorithm used? - Would fixing it require to use a bottom up algorithm for better concurrency (which is certainly non trivial)? - Trying to break the circular locking above, I would first question why does the select transaction need to acquire (and hold) a lock on the root block of the index. Would it be possible to ensure the consistency of the select without locking the index? - The attached test (InsertSelectDeadlock.java) tries to simulate a typical data collection application, it consists of: - an insert thread that inserts records in batch - a select thread that 'processes' the records inserted by the other thread: 'select * from table where id ?' The derby log provides detail about the deadlock trace and stacktraces_during_deadlock.txt shows that the inser thread is doing an index split. The test was run on 10.2.2.0 and 10.3.1.4 with identical behaviour. Thanks, Bogdan Calmac. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-550) BLOB : java.lang.OutOfMemoryError with network JDBC driver (org.apache.derby.jdbc.ClientDriver)
[
https://issues.apache.org/jira/browse/DERBY-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden resolved DERBY-550.
--
Resolution: Fixed
BLOB : java.lang.OutOfMemoryError with network JDBC driver
(org.apache.derby.jdbc.ClientDriver)
---
Key: DERBY-550
URL: https://issues.apache.org/jira/browse/DERBY-550
Project: Derby
Issue Type: Bug
Components: JDBC, Network Server
Affects Versions: 10.1.1.0
Environment: Any environment.
Reporter: Grégoire Dubois
Assignee: Tomohito Nakayama
Attachments: BlobOutOfMem.java
Using the org.apache.derby.jdbc.ClientDriver driver to access the
Derby database through network, the driver is writting all the file into
memory (RAM) before sending
it to the database.
Writting small files (smaller than 5Mo) into the database works fine,
but it is impossible to write big files (40Mo for example, or more), without
getting the
exception java.lang.OutOfMemoryError.
The org.apache.derby.jdbc.EmbeddedDriver doesn't have this problem.
Here follows some code that creates a database, a table, and trys to write a
BLOB. 2 parameters are to be changed for the code to work for you :
DERBY_DBMS_PATH and FILE
import NetNoLedge.Configuration.Configs;
import org.apache.derby.drda.NetworkServerControl;
import java.net.InetAddress;
import java.io.*;
import java.sql.*;
/**
*
* @author greg
*/
public class DerbyServer_JDBC_BLOB_test {
// The unique instance of DerbyServer in the application.
private static DerbyServer_JDBC_BLOB_test derbyServer;
private NetworkServerControl server;
private static final String DERBY_JDBC_DRIVER =
org.apache.derby.jdbc.ClientDriver;
private static final String DERBY_DATABASE_NAME = Test;
// ###
// ### SET HERE THE EXISTING PATH YOU WANT
// ###
private static final String DERBY_DBMS_PATH = /home/greg/DatabaseTest;
// ###
// ###
private static int derbyPort = 9157;
private static String userName = user;
private static String userPassword = password;
//
###
// # DEFINE HERE THE PATH TO THE FILE YOU WANT TO WRITE INTO
THE DATABASE ###
// # TRY A 100kb-3Mb FILE, AND AFTER A 40Mb OR BIGGER FILE
#
//
###
private static final File FILE = new File(/home/greg/01.jpg);
//
###
//
###
/**
* pUsed to test the server.
*/
public static void main(String args[]) {
try {
DerbyServer_JDBC_BLOB_test.launchServer();
DerbyServer_JDBC_BLOB_test server = getUniqueInstance();
server.start();
System.out.println(Server started);
// After the server has been started, launch a first connection
to the database to
// 1) Create the database if it doesn't exist already,
// 2) Create the tables if they don't exist already.
Class.forName(DERBY_JDBC_DRIVER).newInstance();
Connection connection = DriverManager.getConnection
(jdbc:derby://localhost:+derbyPort+/+DERBY_DATABASE_NAME+;create=true,
userName, userPassword);
System.out.println(Network JDBC connection to Derby succeded.
Database created if not created already.);
Statement statement =
connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
Statement statement2;
// Create the table file if it doesn't already exist.
String [] tableNames={file};
boolean exist;
String currentTable;
ResultSet result = statement.executeQuery(SELECT TABLENAME FROM
SYS.SYSTABLES);
for (int i=0;itableNames.length;i++) {
exist=false;
while (result.next()){
if (tableNames[i].equalsIgnoreCase(result.getString(1)))
exist=true;
}
if (!exist) {
statement2 =
Regression Test Report - tinderbox_trunk16 674566 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk16* 674566/2008-07-07 19:52:14 CEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* SunOS-5.10_i86pc-i386 022 0 115.78% org.apache.derbyTesting.functionTests.tests.demo._Suite F:1,E:01019710196 0 1685.58% org.apache.derbyTesting.functionTests.suites.All 0261261 0 111.17% derbyall 022 0 171.65% org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.CompatibilityCombinations 088 0 108.65% org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationSuite Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-674566.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/674566_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/674566.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Closed: (DERBY-3751) Convert case.sql to junit
[ https://issues.apache.org/jira/browse/DERBY-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Junjie Peng closed DERBY-3751. -- It's OK. Thank you, Kristian! Convert case.sql to junit - Key: DERBY-3751 URL: https://issues.apache.org/jira/browse/DERBY-3751 Project: Derby Issue Type: Test Components: Test Environment: Windows Xp, sp2. Reporter: Junjie Peng Assignee: Junjie Peng Fix For: 10.5.0.0 Attachments: derby-3751-1-patch.txt, derby-3751-1-stat.txt, derby-3751-2-patch.txt, derby-3751-2-stat.txt, derby-3751-patch.txt Original Estimate: 72h Remaining Estimate: 72h In the package org.apache.derbyTesting.functionTests.tests.lang, we have both CaseExpressionTest.java and case.sql, which are both about case. Now, I would like to convert case.sql to junit, and I will add new test cases into CaseExpressionTest.java ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
