[jira] Closed: (DERBY-3289) Bracketed comments should be documented in the Derby Tools and Utilities Guide
[ https://issues.apache.org/jira/browse/DERBY-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams closed DERBY-3289. - Bracketed comments should be documented in the Derby Tools and Utilities Guide -- Key: DERBY-3289 URL: https://issues.apache.org/jira/browse/DERBY-3289 Project: Derby Issue Type: New Feature Components: Documentation Affects Versions: 10.4.0.0 Reporter: James F. Adams Assignee: Kim Haase Priority: Minor Fix For: 10.4.0.0 Attachments: DERBY-3289.diff, output1.txt, output2.txt, output3.txt, rtoolsijcomref16653.html Ij was modified by Derby-3242 to recognize bracketed comments. This new feature should be documented in the Derby Tools and Utilities Guide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3289) Bracketed comments should be documented in the Derby Tools and Utilities Guide
[ https://issues.apache.org/jira/browse/DERBY-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567921#action_12567921 ] James F. Adams commented on DERBY-3289: --- Kim, The patch look ok to me. Thank you for your work on this issue. Bracketed comments should be documented in the Derby Tools and Utilities Guide -- Key: DERBY-3289 URL: https://issues.apache.org/jira/browse/DERBY-3289 Project: Derby Issue Type: New Feature Components: Documentation Affects Versions: 10.4.0.0 Reporter: James F. Adams Assignee: Kim Haase Priority: Minor Attachments: DERBY-3289.diff, output1.txt, output2.txt, output3.txt, rtoolsijcomref16653.html Ij was modified by Derby-3242 to recognize bracketed comments. This new feature should be documented in the Derby Tools and Utilities Guide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3289) Bracketed comments should be documented in the Derby Tools and Utilities Guide
[ https://issues.apache.org/jira/browse/DERBY-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3289: -- Attachment: output3.txt output2.txt output1.txt Attached are files output1.txt, output2.txt, and output3.txt. This is the output when running comment.sql, comment2.sql, and comment3.sql that are attached to issue 3242. Bracketed comments should be documented in the Derby Tools and Utilities Guide -- Key: DERBY-3289 URL: https://issues.apache.org/jira/browse/DERBY-3289 Project: Derby Issue Type: New Feature Components: Documentation Affects Versions: 10.4.0.0 Reporter: James F. Adams Assignee: Kim Haase Priority: Minor Attachments: output1.txt, output2.txt, output3.txt Ij was modified by Derby-3242 to recognize bracketed comments. This new feature should be documented in the Derby Tools and Utilities Guide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3289) Bracketed comments should be documented in the Derby Tools and Utilities Guide
Bracketed comments should be documented in the Derby Tools and Utilities Guide -- Key: DERBY-3289 URL: https://issues.apache.org/jira/browse/DERBY-3289 Project: Derby Issue Type: New Feature Components: Documentation Affects Versions: 10.4.0.0 Reporter: James F. Adams Priority: Minor Ij was modified by Derby-3242 to recognize bracketed comments. This new feature should be documented in the Derby Tools and Utilities Guide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3242) ij doesn't understand bracketed comments
[ https://issues.apache.org/jira/browse/DERBY-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3242: -- Attachment: Derby3242-v3.txt Knut, thanks for reviewing the previous patch. I have uploaded another, and hopefully final, patch proposal. I modified ij.jj to recognize nested bracketed comments and added an additional test to IJRunScriptTest.java. Ran derbyAll and suites.All and saw no errors I could attribute to this patch. ij doesn't understand bracketed comments Key: DERBY-3242 URL: https://issues.apache.org/jira/browse/DERBY-3242 Project: Derby Issue Type: Bug Components: SQL, Tools Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: James F. Adams Attachments: comment.sql, comment2.sql, comment3.sql, Derby-3241-v2.txt, Derby-3242.txt, Derby3242-v3.txt When I execute this sql script in ij -- create table t (x int); /* insert into t values 1, 2, 3; insert into t values 4, 5, 6; */ -- the first INSERT statement in the comment is correctly ignored, but the second one is executed. So after running the script, table T contains these rows: ij select * from t; X --- 4 5 6 3 rows selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3242) ij doesn't understand bracketed comments
[ https://issues.apache.org/jira/browse/DERBY-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3242: -- Attachment: Derby-3241-v2.txt Thanks Knut for spending the time to review my previous patch proposal. I have prepared a new patch proposal (Derby-3241-v2.txt) that incorporates your suggestions. In particular: Scripts ending with bracketed comments are correctly handled. I cleaned up the indentation to be in the style of the surrounding code. Added the missing constants and removed the unnecessary state flags. Ran derbyAll and suites.All and saw no errors I could attribute to this patch. ij doesn't understand bracketed comments Key: DERBY-3242 URL: https://issues.apache.org/jira/browse/DERBY-3242 Project: Derby Issue Type: Bug Components: SQL, Tools Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: James F. Adams Attachments: comment.sql, comment2.sql, Derby-3241-v2.txt, Derby-3242.txt When I execute this sql script in ij -- create table t (x int); /* insert into t values 1, 2, 3; insert into t values 4, 5, 6; */ -- the first INSERT statement in the comment is correctly ignored, but the second one is executed. So after running the script, table T contains these rows: ij select * from t; X --- 4 5 6 3 rows selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3242) ij doesn't understand bracketed comments
[ https://issues.apache.org/jira/browse/DERBY-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3242: -- Derby Info: [Patch Available] ij doesn't understand bracketed comments Key: DERBY-3242 URL: https://issues.apache.org/jira/browse/DERBY-3242 Project: Derby Issue Type: Bug Components: SQL, Tools Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: James F. Adams Attachments: comment.sql, Derby-3242.txt When I execute this sql script in ij -- create table t (x int); /* insert into t values 1, 2, 3; insert into t values 4, 5, 6; */ -- the first INSERT statement in the comment is correctly ignored, but the second one is executed. So after running the script, table T contains these rows: ij select * from t; X --- 4 5 6 3 rows selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3242) ij doesn't understand bracketed comments
[ https://issues.apache.org/jira/browse/DERBY-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3242: -- Attachment: Derby-3242.txt Attached a patch proposal that addresses this issue. Modified StatementFinder.java to recognize nested brackted comments. Added a test to IJRunScriptTest.java to verify bracketed comment support in ij. Ran derbyAll and suites.All and saw no errors I could attribute to this patch. ij doesn't understand bracketed comments Key: DERBY-3242 URL: https://issues.apache.org/jira/browse/DERBY-3242 Project: Derby Issue Type: Bug Components: SQL, Tools Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: James F. Adams Attachments: comment.sql, Derby-3242.txt When I execute this sql script in ij -- create table t (x int); /* insert into t values 1, 2, 3; insert into t values 4, 5, 6; */ -- the first INSERT statement in the comment is correctly ignored, but the second one is executed. So after running the script, table T contains these rows: ij select * from t; X --- 4 5 6 3 rows selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3242) ij doesn't understand bracketed comments
[ https://issues.apache.org/jira/browse/DERBY-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams reassigned DERBY-3242: - Assignee: James F. Adams ij doesn't understand bracketed comments Key: DERBY-3242 URL: https://issues.apache.org/jira/browse/DERBY-3242 Project: Derby Issue Type: Bug Components: SQL, Tools Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: James F. Adams Attachments: comment.sql When I execute this sql script in ij -- create table t (x int); /* insert into t values 1, 2, 3; insert into t values 4, 5, 6; */ -- the first INSERT statement in the comment is correctly ignored, but the second one is executed. So after running the script, table T contains these rows: ij select * from t; X --- 4 5 6 3 rows selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3241) No syntax error when compiling statement with unterminated comment
[ https://issues.apache.org/jira/browse/DERBY-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3241: -- Attachment: Derby-3241-2.diff Thanks for reviewing my patch, Knut. I have attached an updated version of the patch that handles the example you described and added an additional test. suites.All and derbyall ran without new errors. No syntax error when compiling statement with unterminated comment -- Key: DERBY-3241 URL: https://issues.apache.org/jira/browse/DERBY-3241 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: James F. Adams Priority: Minor Attachments: Derby-3241-2.diff, Derby-3241.diff Compiling a statement with an unterminated comment doesn't raise a syntax error. ij prepare p as 'values 1 /* unterminated comment '; ij execute p; 1 --- 1 1 row selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3241) No syntax error when compiling statement with unterminated comment
[ https://issues.apache.org/jira/browse/DERBY-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams reassigned DERBY-3241: - Assignee: James F. Adams No syntax error when compiling statement with unterminated comment -- Key: DERBY-3241 URL: https://issues.apache.org/jira/browse/DERBY-3241 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: James F. Adams Priority: Minor Compiling a statement with an unterminated comment doesn't raise a syntax error. ij prepare p as 'values 1 /* unterminated comment '; ij execute p; 1 --- 1 1 row selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3241) No syntax error when compiling statement with unterminated comment
[ https://issues.apache.org/jira/browse/DERBY-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3241: -- Attachment: Derby-3241.diff Attached a patch proposal (Derby-3241.diff) that I believe resolves this issue. The patch modifies sqlgrammar.jj to detect unterminated bracketed comments by correcting the use of SKIP and MORE regular expressions. I also added some tests to CommentTest.java to check for unterminated bracketed comments. No syntax error when compiling statement with unterminated comment -- Key: DERBY-3241 URL: https://issues.apache.org/jira/browse/DERBY-3241 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: James F. Adams Priority: Minor Attachments: Derby-3241.diff Compiling a statement with an unterminated comment doesn't raise a syntax error. ij prepare p as 'values 1 /* unterminated comment '; ij execute p; 1 --- 1 1 row selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3241) No syntax error when compiling statement with unterminated comment
[ https://issues.apache.org/jira/browse/DERBY-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3241: -- Derby Info: [Patch Available] suites.All and derbyall ran with no new errors. Set patch available. No syntax error when compiling statement with unterminated comment -- Key: DERBY-3241 URL: https://issues.apache.org/jira/browse/DERBY-3241 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: James F. Adams Priority: Minor Attachments: Derby-3241.diff Compiling a statement with an unterminated comment doesn't raise a syntax error. ij prepare p as 'values 1 /* unterminated comment '; ij execute p; 1 --- 1 1 row selected -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3157) Lexical error (EOF) when comment consists of a single character
[ https://issues.apache.org/jira/browse/DERBY-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams reassigned DERBY-3157: - Assignee: (was: James F. Adams) Lexical error (EOF) when comment consists of a single character --- Key: DERBY-3157 URL: https://issues.apache.org/jira/browse/DERBY-3157 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.1.4, 10.4.0.0 Reporter: Knut Anders Hatlen Priority: Minor Attachments: DERBY-3157.diff The following statement fails with an SQLException. Adding whitespace or other characters at the end of the comment makes it pass. Adding more whitespace at the beginning of the comment doesn't help. PreparedStatement ps = c.prepareStatement(VALUES 1 -- x); Exception in thread main java.sql.SQLSyntaxErrorException: Lexical error at line 1, column 14. Encountered: EOF after : . at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown Source) at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at comment.main(comment.java:5) Caused by: java.sql.SQLException: Lexical error at line 1, column 14. Encountered: EOF after : . at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 14 more Caused by: ERROR 42X02: Lexical error at line 1, column 14. Encountered: EOF after : . at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(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) ... 8 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3119) Derby does not resolve functions to methods with Integer return type.
[
https://issues.apache.org/jira/browse/DERBY-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544868
]
James F. Adams commented on DERBY-3119:
---
Would it be possible for someone to merge this to the 10.3 branch?
Derby does not resolve functions to methods with Integer return type.
-
Key: DERBY-3119
URL: https://issues.apache.org/jira/browse/DERBY-3119
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0,
10.3.1.4
Reporter: Rick Hillegas
Assignee: James F. Adams
Fix For: 10.4.0.0
Attachments: derby-3119-1_diff.txt
Derby can bind a function invocation to a method which returns int but not to
a method which returns Integer. I think that both of these resolutions should
succeed given the rules in the SQL Standard, part 13, section 8.6, syntax
rule 5, case a, item ii. Here is some code which shows this problem. First a
class to declare the methods:
public class zz
{
public static int returnsInt()
{
return 1;
}
public static Integer returnsInteger()
{
return new Integer( 2 );
}
}
The following ij script shows that the int-returning method is resolved but
not the Integer-returning method:
ij version 10.4
ij connect 'jdbc:derby:derby10.4;create=true';
WARNING 01J01: Database 'derby10.4' not created, connection made to existing
database instead.
ij drop function returnsInt;
0 rows inserted/updated/deleted
ij drop function returnsInteger;
0 rows inserted/updated/deleted
ij create function returnsInt()
returns int
language java
parameter style java
no sql
external name 'zz.returnsInt'
;
0 rows inserted/updated/deleted
ij create function returnsInteger()
returns int
language java
parameter style java
no sql
external name 'zz.returnsInteger'
;
0 rows inserted/updated/deleted
ij values ( returnsInt() );
1
---
1
1 row selected
ij values ( returnsInteger() );
ERROR 42X50: No method was found that matched the method call int
zz.returnsInteger(), tried all combinations of object and primitive types and
any possible type conversion for any parameters the method call may have.
The method might exist but it is not public and/or static, or the parameter
types are not method invocation convertible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3157) Lexical error (EOF) when comment consists of a single character
[ https://issues.apache.org/jira/browse/DERBY-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams reassigned DERBY-3157: - Assignee: James F. Adams Lexical error (EOF) when comment consists of a single character --- Key: DERBY-3157 URL: https://issues.apache.org/jira/browse/DERBY-3157 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.1.4, 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: James F. Adams Priority: Minor The following statement fails with an SQLException. Adding whitespace or other characters at the end of the comment makes it pass. Adding more whitespace at the beginning of the comment doesn't help. PreparedStatement ps = c.prepareStatement(VALUES 1 -- x); Exception in thread main java.sql.SQLSyntaxErrorException: Lexical error at line 1, column 14. Encountered: EOF after : . at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown Source) at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at comment.main(comment.java:5) Caused by: java.sql.SQLException: Lexical error at line 1, column 14. Encountered: EOF after : . at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 14 more Caused by: ERROR 42X02: Lexical error at line 1, column 14. Encountered: EOF after : . at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(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) ... 8 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3157) Lexical error (EOF) when comment consists of a single character
[ https://issues.apache.org/jira/browse/DERBY-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3157: -- Derby Info: [Patch Available] Lexical error (EOF) when comment consists of a single character --- Key: DERBY-3157 URL: https://issues.apache.org/jira/browse/DERBY-3157 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.1.4, 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: James F. Adams Priority: Minor Attachments: DERBY-3157.diff The following statement fails with an SQLException. Adding whitespace or other characters at the end of the comment makes it pass. Adding more whitespace at the beginning of the comment doesn't help. PreparedStatement ps = c.prepareStatement(VALUES 1 -- x); Exception in thread main java.sql.SQLSyntaxErrorException: Lexical error at line 1, column 14. Encountered: EOF after : . at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown Source) at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at comment.main(comment.java:5) Caused by: java.sql.SQLException: Lexical error at line 1, column 14. Encountered: EOF after : . at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 14 more Caused by: ERROR 42X02: Lexical error at line 1, column 14. Encountered: EOF after : . at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(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) ... 8 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3157) Lexical error (EOF) when comment consists of a single character
[ https://issues.apache.org/jira/browse/DERBY-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3157: -- Attachment: DERBY-3157.diff Attached patch proposal DERBY-3157.diff for review. I simplified the processing of end of line comments in order to correct certain termination conditions. A few addtional tests were added. Running derbyall and suites.All. Lexical error (EOF) when comment consists of a single character --- Key: DERBY-3157 URL: https://issues.apache.org/jira/browse/DERBY-3157 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.1.4, 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: James F. Adams Priority: Minor Attachments: DERBY-3157.diff The following statement fails with an SQLException. Adding whitespace or other characters at the end of the comment makes it pass. Adding more whitespace at the beginning of the comment doesn't help. PreparedStatement ps = c.prepareStatement(VALUES 1 -- x); Exception in thread main java.sql.SQLSyntaxErrorException: Lexical error at line 1, column 14. Encountered: EOF after : . at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown Source) at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at comment.main(comment.java:5) Caused by: java.sql.SQLException: Lexical error at line 1, column 14. Encountered: EOF after : . at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 14 more Caused by: ERROR 42X02: Lexical error at line 1, column 14. Encountered: EOF after : . at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(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) ... 8 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3157) Lexical error (EOF) when comment consists of a single character
[ https://issues.apache.org/jira/browse/DERBY-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3157: -- Derby Info: (was: [Patch Available]) Removing patch available flag. An error occurs in derbyAll. I am investigating and will post a new patch when fixed. Lexical error (EOF) when comment consists of a single character --- Key: DERBY-3157 URL: https://issues.apache.org/jira/browse/DERBY-3157 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.1.4, 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: James F. Adams Priority: Minor Attachments: DERBY-3157.diff The following statement fails with an SQLException. Adding whitespace or other characters at the end of the comment makes it pass. Adding more whitespace at the beginning of the comment doesn't help. PreparedStatement ps = c.prepareStatement(VALUES 1 -- x); Exception in thread main java.sql.SQLSyntaxErrorException: Lexical error at line 1, column 14. Encountered: EOF after : . at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown Source) at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at comment.main(comment.java:5) Caused by: java.sql.SQLException: Lexical error at line 1, column 14. Encountered: EOF after : . at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 14 more Caused by: ERROR 42X02: Lexical error at line 1, column 14. Encountered: EOF after : . at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(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) ... 8 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1749) Implement Bracketed SQL comments (/*...*/ comments)
[ https://issues.apache.org/jira/browse/DERBY-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-1749: -- Attachment: Derby-1749-3.diff Attached new patch (Derby-1749-3.diff) that adds some simple bracketed comment tests. Implement Bracketed SQL comments (/*...*/ comments) --- Key: DERBY-1749 URL: https://issues.apache.org/jira/browse/DERBY-1749 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4 Reporter: Conny Kreyßel Attachments: d1749-ref-single.html.diff, d1749-rrefsqlj28468.html.diff, Derby-1749-2.txt, Derby-1749-3.diff, DERBY-1749.diff Hibernate use multiline sql statements to show the internal building of the hql statements. You can disable this feature, but it would be nice if you can implements bracketed SQL comments in Derby. 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-1749) Implement Bracketed SQL comments (/*...*/ comments)
[ https://issues.apache.org/jira/browse/DERBY-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-1749: -- Derby Info: [Patch Available] Implement Bracketed SQL comments (/*...*/ comments) --- Key: DERBY-1749 URL: https://issues.apache.org/jira/browse/DERBY-1749 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4 Reporter: Conny Kreyßel Attachments: d1749-ref-single.html.diff, d1749-rrefsqlj28468.html.diff, Derby-1749-2.txt, Derby-1749-3.diff, DERBY-1749.diff Hibernate use multiline sql statements to show the internal building of the hql statements. You can disable this feature, but it would be nice if you can implements bracketed SQL comments in Derby. 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-1749) Implement Bracketed SQL comments (/*...*/ comments)
[ https://issues.apache.org/jira/browse/DERBY-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-1749: -- Attachment: Derby-1749-2.txt Derby-1749-2 is an updated patch to sqlgrammar.jj which implements nested bracketed comments. Not a complete patch; no tests added yet. Implement Bracketed SQL comments (/*...*/ comments) --- Key: DERBY-1749 URL: https://issues.apache.org/jira/browse/DERBY-1749 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4 Reporter: Conny Kreyßel Attachments: Derby-1749-2.txt, DERBY-1749.diff Hibernate use multiline sql statements to show the internal building of the hql statements. You can disable this feature, but it would be nice if you can implements bracketed SQL comments in Derby. 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-3119) Derby does not resolve functions to methods with Integer return type.
[
https://issues.apache.org/jira/browse/DERBY-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James F. Adams updated DERBY-3119:
--
Fix Version/s: 10.4.0.0
Derby does not resolve functions to methods with Integer return type.
-
Key: DERBY-3119
URL: https://issues.apache.org/jira/browse/DERBY-3119
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0,
10.3.1.4
Reporter: Rick Hillegas
Assignee: James F. Adams
Fix For: 10.4.0.0
Attachments: derby-3119-1_diff.txt
Derby can bind a function invocation to a method which returns int but not to
a method which returns Integer. I think that both of these resolutions should
succeed given the rules in the SQL Standard, part 13, section 8.6, syntax
rule 5, case a, item ii. Here is some code which shows this problem. First a
class to declare the methods:
public class zz
{
public static int returnsInt()
{
return 1;
}
public static Integer returnsInteger()
{
return new Integer( 2 );
}
}
The following ij script shows that the int-returning method is resolved but
not the Integer-returning method:
ij version 10.4
ij connect 'jdbc:derby:derby10.4;create=true';
WARNING 01J01: Database 'derby10.4' not created, connection made to existing
database instead.
ij drop function returnsInt;
0 rows inserted/updated/deleted
ij drop function returnsInteger;
0 rows inserted/updated/deleted
ij create function returnsInt()
returns int
language java
parameter style java
no sql
external name 'zz.returnsInt'
;
0 rows inserted/updated/deleted
ij create function returnsInteger()
returns int
language java
parameter style java
no sql
external name 'zz.returnsInteger'
;
0 rows inserted/updated/deleted
ij values ( returnsInt() );
1
---
1
1 row selected
ij values ( returnsInteger() );
ERROR 42X50: No method was found that matched the method call int
zz.returnsInteger(), tried all combinations of object and primitive types and
any possible type conversion for any parameters the method call may have.
The method might exist but it is not public and/or static, or the parameter
types are not method invocation convertible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3119) Derby does not resolve functions to methods with Integer return type.
[
https://issues.apache.org/jira/browse/DERBY-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James F. Adams resolved DERBY-3119.
---
Resolution: Fixed
Derby Info: (was: [Patch Available])
Derby does not resolve functions to methods with Integer return type.
-
Key: DERBY-3119
URL: https://issues.apache.org/jira/browse/DERBY-3119
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0,
10.3.1.4
Reporter: Rick Hillegas
Assignee: James F. Adams
Attachments: derby-3119-1_diff.txt
Derby can bind a function invocation to a method which returns int but not to
a method which returns Integer. I think that both of these resolutions should
succeed given the rules in the SQL Standard, part 13, section 8.6, syntax
rule 5, case a, item ii. Here is some code which shows this problem. First a
class to declare the methods:
public class zz
{
public static int returnsInt()
{
return 1;
}
public static Integer returnsInteger()
{
return new Integer( 2 );
}
}
The following ij script shows that the int-returning method is resolved but
not the Integer-returning method:
ij version 10.4
ij connect 'jdbc:derby:derby10.4;create=true';
WARNING 01J01: Database 'derby10.4' not created, connection made to existing
database instead.
ij drop function returnsInt;
0 rows inserted/updated/deleted
ij drop function returnsInteger;
0 rows inserted/updated/deleted
ij create function returnsInt()
returns int
language java
parameter style java
no sql
external name 'zz.returnsInt'
;
0 rows inserted/updated/deleted
ij create function returnsInteger()
returns int
language java
parameter style java
no sql
external name 'zz.returnsInteger'
;
0 rows inserted/updated/deleted
ij values ( returnsInt() );
1
---
1
1 row selected
ij values ( returnsInteger() );
ERROR 42X50: No method was found that matched the method call int
zz.returnsInteger(), tried all combinations of object and primitive types and
any possible type conversion for any parameters the method call may have.
The method might exist but it is not public and/or static, or the parameter
types are not method invocation convertible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3119) Derby does not resolve functions to methods with Integer return type.
[
https://issues.apache.org/jira/browse/DERBY-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James F. Adams reassigned DERBY-3119:
-
Assignee: James F. Adams
Derby does not resolve functions to methods with Integer return type.
-
Key: DERBY-3119
URL: https://issues.apache.org/jira/browse/DERBY-3119
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0,
10.3.1.4
Reporter: Rick Hillegas
Assignee: James F. Adams
Derby can bind a function invocation to a method which returns int but not to
a method which returns Integer. I think that both of these resolutions should
succeed given the rules in the SQL Standard, part 13, section 8.6, syntax
rule 5, case a, item ii. Here is some code which shows this problem. First a
class to declare the methods:
public class zz
{
public static int returnsInt()
{
return 1;
}
public static Integer returnsInteger()
{
return new Integer( 2 );
}
}
The following ij script shows that the int-returning method is resolved but
not the Integer-returning method:
ij version 10.4
ij connect 'jdbc:derby:derby10.4;create=true';
WARNING 01J01: Database 'derby10.4' not created, connection made to existing
database instead.
ij drop function returnsInt;
0 rows inserted/updated/deleted
ij drop function returnsInteger;
0 rows inserted/updated/deleted
ij create function returnsInt()
returns int
language java
parameter style java
no sql
external name 'zz.returnsInt'
;
0 rows inserted/updated/deleted
ij create function returnsInteger()
returns int
language java
parameter style java
no sql
external name 'zz.returnsInteger'
;
0 rows inserted/updated/deleted
ij values ( returnsInt() );
1
---
1
1 row selected
ij values ( returnsInteger() );
ERROR 42X50: No method was found that matched the method call int
zz.returnsInteger(), tried all combinations of object and primitive types and
any possible type conversion for any parameters the method call may have.
The method might exist but it is not public and/or static, or the parameter
types are not method invocation convertible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3119) Derby does not resolve functions to methods with Integer return type.
[
https://issues.apache.org/jira/browse/DERBY-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James F. Adams updated DERBY-3119:
--
Attachment: derby-3119-1_diff.txt
Attached is a patch proposal that I believe corrects the problem.
The resolveMethodCall method of MethodCallNode has been modified to properly
validate return types SMALLINT, INTEGER, BIGINT, REAL, and DOUBLE. These types
are object mappable to Integer, Integer, Long, Float, and Double as well as
simply mappable to short, int, long, float, and double.
In addition I added tests to RoutineTest.
Ran Derbyall and suites.All with no new errors.
Derby does not resolve functions to methods with Integer return type.
-
Key: DERBY-3119
URL: https://issues.apache.org/jira/browse/DERBY-3119
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0,
10.3.1.4
Reporter: Rick Hillegas
Assignee: James F. Adams
Attachments: derby-3119-1_diff.txt
Derby can bind a function invocation to a method which returns int but not to
a method which returns Integer. I think that both of these resolutions should
succeed given the rules in the SQL Standard, part 13, section 8.6, syntax
rule 5, case a, item ii. Here is some code which shows this problem. First a
class to declare the methods:
public class zz
{
public static int returnsInt()
{
return 1;
}
public static Integer returnsInteger()
{
return new Integer( 2 );
}
}
The following ij script shows that the int-returning method is resolved but
not the Integer-returning method:
ij version 10.4
ij connect 'jdbc:derby:derby10.4;create=true';
WARNING 01J01: Database 'derby10.4' not created, connection made to existing
database instead.
ij drop function returnsInt;
0 rows inserted/updated/deleted
ij drop function returnsInteger;
0 rows inserted/updated/deleted
ij create function returnsInt()
returns int
language java
parameter style java
no sql
external name 'zz.returnsInt'
;
0 rows inserted/updated/deleted
ij create function returnsInteger()
returns int
language java
parameter style java
no sql
external name 'zz.returnsInteger'
;
0 rows inserted/updated/deleted
ij values ( returnsInt() );
1
---
1
1 row selected
ij values ( returnsInteger() );
ERROR 42X50: No method was found that matched the method call int
zz.returnsInteger(), tried all combinations of object and primitive types and
any possible type conversion for any parameters the method call may have.
The method might exist but it is not public and/or static, or the parameter
types are not method invocation convertible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3119) Derby does not resolve functions to methods with Integer return type.
[
https://issues.apache.org/jira/browse/DERBY-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James F. Adams updated DERBY-3119:
--
Derby Info: [Patch Available]
Derby does not resolve functions to methods with Integer return type.
-
Key: DERBY-3119
URL: https://issues.apache.org/jira/browse/DERBY-3119
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0,
10.3.1.4
Reporter: Rick Hillegas
Assignee: James F. Adams
Attachments: derby-3119-1_diff.txt
Derby can bind a function invocation to a method which returns int but not to
a method which returns Integer. I think that both of these resolutions should
succeed given the rules in the SQL Standard, part 13, section 8.6, syntax
rule 5, case a, item ii. Here is some code which shows this problem. First a
class to declare the methods:
public class zz
{
public static int returnsInt()
{
return 1;
}
public static Integer returnsInteger()
{
return new Integer( 2 );
}
}
The following ij script shows that the int-returning method is resolved but
not the Integer-returning method:
ij version 10.4
ij connect 'jdbc:derby:derby10.4;create=true';
WARNING 01J01: Database 'derby10.4' not created, connection made to existing
database instead.
ij drop function returnsInt;
0 rows inserted/updated/deleted
ij drop function returnsInteger;
0 rows inserted/updated/deleted
ij create function returnsInt()
returns int
language java
parameter style java
no sql
external name 'zz.returnsInt'
;
0 rows inserted/updated/deleted
ij create function returnsInteger()
returns int
language java
parameter style java
no sql
external name 'zz.returnsInteger'
;
0 rows inserted/updated/deleted
ij values ( returnsInt() );
1
---
1
1 row selected
ij values ( returnsInteger() );
ERROR 42X50: No method was found that matched the method call int
zz.returnsInteger(), tried all combinations of object and primitive types and
any possible type conversion for any parameters the method call may have.
The method might exist but it is not public and/or static, or the parameter
types are not method invocation convertible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DERBY-3093) Intermittent transaction failure caused by internal duplicate savepoint name for triggers
[ https://issues.apache.org/jira/browse/DERBY-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537194 ] james.f.adams edited comment on DERBY-3093 at 10/25/07 1:13 AM: - Updated patch replacing internalSavePointName = ISSP + lcc.getUniqueSavepointName(); with internalSavePointName = lcc.getUniqueSavepointName(); Ran Derbyall and suites.All with no new errors. was (Author: james.f.adams): Updated patch replacing internalSavePointName = ISSP + lcc.getUniqueSavepointName(); with internalSavePointName = lcc.getUniqueSavepointName(); Intermittent transaction failure caused by internal duplicate savepoint name for triggers - Key: DERBY-3093 URL: https://issues.apache.org/jira/browse/DERBY-3093 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.1.4 Environment: Java 1.6.0_02 Reporter: Jim Newsham Assignee: James F. Adams Fix For: 10.4.0.0 Attachments: derby-3093-2_diff.txt, derby-3093-3_diff.txt, derby-3093_diff.txt While running our app overnight, performing some intensive database operations (primarily deletes), we experienced a transaction failure, with error message A SAVEPOINT with the passed name already exists in the current transaction. This failure appears to be very intermittent, as I've run the same operation successfully for hours and hours without failure. Some more information: 1. I see that there are four JIRA issues which report the same message (DERBY-2773, DERBY-1457, DERBY-2808, DERBY-2804). I am not sure to what extent if any, the problem I experienced is related to these issues. • At least three of the above JIRA issues are related to triggers. Our transaction failure occurred while performing a delete in a table which has delete triggers. • We aren't using savepoints explicitly. Of course, it can be seen in the stack trace that the trigger operation is setting a savepoint. • One of the JIRA issues mentions exceeding maximum depth of nested triggers. Not sure what a nested trigger is, but the trigger we are performing should not (in theory) cause another trigger event. 2. Here's the stack trace: Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase$3.perform(DerbySampleBase.java:682) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase.performInTransaction(DerbySampleBase.java:2747) ... 7 more Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 18 more Caused by: ERROR 3B501: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.setSavePoint(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.conn.GenericStatementContext.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.fireAfterTriggers(Unknown Source)
[jira] Resolved: (DERBY-3093) Intermittent transaction failure caused by internal duplicate savepoint name for triggers
[ https://issues.apache.org/jira/browse/DERBY-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams resolved DERBY-3093. --- Resolution: Fixed Intermittent transaction failure caused by internal duplicate savepoint name for triggers - Key: DERBY-3093 URL: https://issues.apache.org/jira/browse/DERBY-3093 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.1.4 Environment: Java 1.6.0_02 Reporter: Jim Newsham Assignee: James F. Adams Fix For: 10.4.0.0 Attachments: derby-3093-2_diff.txt, derby-3093-3_diff.txt, derby-3093_diff.txt While running our app overnight, performing some intensive database operations (primarily deletes), we experienced a transaction failure, with error message A SAVEPOINT with the passed name already exists in the current transaction. This failure appears to be very intermittent, as I've run the same operation successfully for hours and hours without failure. Some more information: 1. I see that there are four JIRA issues which report the same message (DERBY-2773, DERBY-1457, DERBY-2808, DERBY-2804). I am not sure to what extent if any, the problem I experienced is related to these issues. • At least three of the above JIRA issues are related to triggers. Our transaction failure occurred while performing a delete in a table which has delete triggers. • We aren't using savepoints explicitly. Of course, it can be seen in the stack trace that the trigger operation is setting a savepoint. • One of the JIRA issues mentions exceeding maximum depth of nested triggers. Not sure what a nested trigger is, but the trigger we are performing should not (in theory) cause another trigger event. 2. Here's the stack trace: Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase$3.perform(DerbySampleBase.java:682) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase.performInTransaction(DerbySampleBase.java:2747) ... 7 more Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 18 more Caused by: ERROR 3B501: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.setSavePoint(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.conn.GenericStatementContext.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.fireAfterTriggers(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 12 more 3. Here are the relevant tables and triggers. We have different tables for different sample data types in our application (currently int, long, float, double, Boolean, string). I have shown the int_sample table; the other tables are
[jira] Updated: (DERBY-3093) Intermittent transaction failure caused by internal duplicate savepoint name for triggers
[ https://issues.apache.org/jira/browse/DERBY-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3093: -- Derby Info: [Patch Available] Intermittent transaction failure caused by internal duplicate savepoint name for triggers - Key: DERBY-3093 URL: https://issues.apache.org/jira/browse/DERBY-3093 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.1.4 Environment: Java 1.6.0_02 Reporter: Jim Newsham Assignee: James F. Adams Fix For: 10.4.0.0 Attachments: derby-3093-2_diff.txt, derby-3093_diff.txt While running our app overnight, performing some intensive database operations (primarily deletes), we experienced a transaction failure, with error message A SAVEPOINT with the passed name already exists in the current transaction. This failure appears to be very intermittent, as I've run the same operation successfully for hours and hours without failure. Some more information: 1. I see that there are four JIRA issues which report the same message (DERBY-2773, DERBY-1457, DERBY-2808, DERBY-2804). I am not sure to what extent if any, the problem I experienced is related to these issues. • At least three of the above JIRA issues are related to triggers. Our transaction failure occurred while performing a delete in a table which has delete triggers. • We aren't using savepoints explicitly. Of course, it can be seen in the stack trace that the trigger operation is setting a savepoint. • One of the JIRA issues mentions exceeding maximum depth of nested triggers. Not sure what a nested trigger is, but the trigger we are performing should not (in theory) cause another trigger event. 2. Here's the stack trace: Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase$3.perform(DerbySampleBase.java:682) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase.performInTransaction(DerbySampleBase.java:2747) ... 7 more Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 18 more Caused by: ERROR 3B501: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.setSavePoint(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.conn.GenericStatementContext.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.fireAfterTriggers(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 12 more 3. Here are the relevant tables and triggers. We have different tables for different sample data types in our application (currently int, long, float, double, Boolean, string). I have shown the int_sample table; the other tables are identical but have a
[jira] Updated: (DERBY-3093) Intermittent transaction failure caused by internal duplicate savepoint name for triggers
[ https://issues.apache.org/jira/browse/DERBY-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3093: -- Attachment: derby-3093-2_diff.txt Attached is an updated patch proposal that uses LanguageConnectionContext.getUniqueSavepointName to generate the savepoint names. The test cannons for savepointJdbc30_JSR169 and savepointJdbc30_XA needed to be modified as some exception text was affected by the change. Ran Derbyall and suites.All with no new errors. Intermittent transaction failure caused by internal duplicate savepoint name for triggers - Key: DERBY-3093 URL: https://issues.apache.org/jira/browse/DERBY-3093 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.1.4 Environment: Java 1.6.0_02 Reporter: Jim Newsham Assignee: James F. Adams Fix For: 10.4.0.0 Attachments: derby-3093-2_diff.txt, derby-3093_diff.txt While running our app overnight, performing some intensive database operations (primarily deletes), we experienced a transaction failure, with error message A SAVEPOINT with the passed name already exists in the current transaction. This failure appears to be very intermittent, as I've run the same operation successfully for hours and hours without failure. Some more information: 1. I see that there are four JIRA issues which report the same message (DERBY-2773, DERBY-1457, DERBY-2808, DERBY-2804). I am not sure to what extent if any, the problem I experienced is related to these issues. • At least three of the above JIRA issues are related to triggers. Our transaction failure occurred while performing a delete in a table which has delete triggers. • We aren't using savepoints explicitly. Of course, it can be seen in the stack trace that the trigger operation is setting a savepoint. • One of the JIRA issues mentions exceeding maximum depth of nested triggers. Not sure what a nested trigger is, but the trigger we are performing should not (in theory) cause another trigger event. 2. Here's the stack trace: Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase$3.perform(DerbySampleBase.java:682) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase.performInTransaction(DerbySampleBase.java:2747) ... 7 more Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 18 more Caused by: ERROR 3B501: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.setSavePoint(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.conn.GenericStatementContext.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.fireAfterTriggers(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.open(Unknown Source) at
[jira] Updated: (DERBY-3093) Intermittent transaction failure caused by internal duplicate savepoint name for triggers
[ https://issues.apache.org/jira/browse/DERBY-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3093: -- Attachment: derby-3093-3_diff.txt Updated patch replacing internalSavePointName = ISSP + lcc.getUniqueSavepointName(); with internalSavePointName = lcc.getUniqueSavepointName(); Intermittent transaction failure caused by internal duplicate savepoint name for triggers - Key: DERBY-3093 URL: https://issues.apache.org/jira/browse/DERBY-3093 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.1.4 Environment: Java 1.6.0_02 Reporter: Jim Newsham Assignee: James F. Adams Fix For: 10.4.0.0 Attachments: derby-3093-2_diff.txt, derby-3093-3_diff.txt, derby-3093_diff.txt While running our app overnight, performing some intensive database operations (primarily deletes), we experienced a transaction failure, with error message A SAVEPOINT with the passed name already exists in the current transaction. This failure appears to be very intermittent, as I've run the same operation successfully for hours and hours without failure. Some more information: 1. I see that there are four JIRA issues which report the same message (DERBY-2773, DERBY-1457, DERBY-2808, DERBY-2804). I am not sure to what extent if any, the problem I experienced is related to these issues. • At least three of the above JIRA issues are related to triggers. Our transaction failure occurred while performing a delete in a table which has delete triggers. • We aren't using savepoints explicitly. Of course, it can be seen in the stack trace that the trigger operation is setting a savepoint. • One of the JIRA issues mentions exceeding maximum depth of nested triggers. Not sure what a nested trigger is, but the trigger we are performing should not (in theory) cause another trigger event. 2. Here's the stack trace: Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase$3.perform(DerbySampleBase.java:682) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase.performInTransaction(DerbySampleBase.java:2747) ... 7 more Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 18 more Caused by: ERROR 3B501: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.setSavePoint(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.conn.GenericStatementContext.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.fireAfterTriggers(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 12 more 3. Here are the relevant tables and triggers. We have different tables for different
[jira] Commented: (DERBY-3093) Intermittent transaction failure caused by internal duplicate savepoint name for triggers
[ https://issues.apache.org/jira/browse/DERBY-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536873 ] James F. Adams commented on DERBY-3093: --- I will attempt to make the necessary changes. In looking a bit further I found that the LanguageConnectionContext that is passed into the constructor for GenericStatementContext has a method called getUniqueSavepointName that has the following description: Get a connection unique system generated name for an unnamed savepoint. Would it be appropriate to use this method to create the savepoint name? If so I will create a new patch that incorporates it. Intermittent transaction failure caused by internal duplicate savepoint name for triggers - Key: DERBY-3093 URL: https://issues.apache.org/jira/browse/DERBY-3093 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.1.4 Environment: Java 1.6.0_02 Reporter: Jim Newsham Assignee: James F. Adams Fix For: 10.2.2.1, 10.3.1.5, 10.4.0.0 Attachments: derby-3093_diff.txt While running our app overnight, performing some intensive database operations (primarily deletes), we experienced a transaction failure, with error message A SAVEPOINT with the passed name already exists in the current transaction. This failure appears to be very intermittent, as I've run the same operation successfully for hours and hours without failure. Some more information: 1. I see that there are four JIRA issues which report the same message (DERBY-2773, DERBY-1457, DERBY-2808, DERBY-2804). I am not sure to what extent if any, the problem I experienced is related to these issues. • At least three of the above JIRA issues are related to triggers. Our transaction failure occurred while performing a delete in a table which has delete triggers. • We aren't using savepoints explicitly. Of course, it can be seen in the stack trace that the trigger operation is setting a savepoint. • One of the JIRA issues mentions exceeding maximum depth of nested triggers. Not sure what a nested trigger is, but the trigger we are performing should not (in theory) cause another trigger event. 2. Here's the stack trace: Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase$3.perform(DerbySampleBase.java:682) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase.performInTransaction(DerbySampleBase.java:2747) ... 7 more Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 18 more Caused by: ERROR 3B501: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.setSavePoint(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.conn.GenericStatementContext.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown Source) at
[jira] Commented: (DERBY-3093) Intermittent transaction failure caused by internal duplicate savepoint name for triggers
[ https://issues.apache.org/jira/browse/DERBY-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536529 ] James F. Adams commented on DERBY-3093: --- Bryan, With regards to your comments: 1) Yes it was intentional. It seemed the most straight forward to implement the name creation without making it unique per transaction. 2) I am not sure how we could test this but any suggestions are of course welcome. Intermittent transaction failure caused by internal duplicate savepoint name for triggers - Key: DERBY-3093 URL: https://issues.apache.org/jira/browse/DERBY-3093 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.1.4 Environment: Java 1.6.0_02 Reporter: Jim Newsham Assignee: James F. Adams Attachments: derby-3093_diff.txt While running our app overnight, performing some intensive database operations (primarily deletes), we experienced a transaction failure, with error message A SAVEPOINT with the passed name already exists in the current transaction. This failure appears to be very intermittent, as I've run the same operation successfully for hours and hours without failure. Some more information: 1. I see that there are four JIRA issues which report the same message (DERBY-2773, DERBY-1457, DERBY-2808, DERBY-2804). I am not sure to what extent if any, the problem I experienced is related to these issues. • At least three of the above JIRA issues are related to triggers. Our transaction failure occurred while performing a delete in a table which has delete triggers. • We aren't using savepoints explicitly. Of course, it can be seen in the stack trace that the trigger operation is setting a savepoint. • One of the JIRA issues mentions exceeding maximum depth of nested triggers. Not sure what a nested trigger is, but the trigger we are performing should not (in theory) cause another trigger event. 2. Here's the stack trace: Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase$3.perform(DerbySampleBase.java:682) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase.performInTransaction(DerbySampleBase.java:2747) ... 7 more Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 18 more Caused by: ERROR 3B501: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.setSavePoint(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.conn.GenericStatementContext.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.fireAfterTriggers(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 12 more 3. Here are the relevant tables and triggers. We have
[jira] Assigned: (DERBY-3093) intermittent transaction failure caused by internal duplicate savepoint name, for tirgger
[ https://issues.apache.org/jira/browse/DERBY-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams reassigned DERBY-3093: - Assignee: James F. Adams intermittent transaction failure caused by internal duplicate savepoint name, for tirgger - Key: DERBY-3093 URL: https://issues.apache.org/jira/browse/DERBY-3093 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4 Environment: Java 1.6.0_02 Reporter: Jim Newsham Assignee: James F. Adams While running our app overnight, performing some intensive database operations (primarily deletes), we experienced a transaction failure, with error message A SAVEPOINT with the passed name already exists in the current transaction. This failure appears to be very intermittent, as I've run the same operation successfully for hours and hours without failure. Some more information: 1. I see that there are four JIRA issues which report the same message (DERBY-2773, DERBY-1457, DERBY-2808, DERBY-2804). I am not sure to what extent if any, the problem I experienced is related to these issues. • At least three of the above JIRA issues are related to triggers. Our transaction failure occurred while performing a delete in a table which has delete triggers. • We aren't using savepoints explicitly. Of course, it can be seen in the stack trace that the trigger operation is setting a savepoint. • One of the JIRA issues mentions exceeding maximum depth of nested triggers. Not sure what a nested trigger is, but the trigger we are performing should not (in theory) cause another trigger event. 2. Here's the stack trace: Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase$3.perform(DerbySampleBase.java:682) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase.performInTransaction(DerbySampleBase.java:2747) ... 7 more Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 18 more Caused by: ERROR 3B501: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.setSavePoint(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.conn.GenericStatementContext.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.fireAfterTriggers(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 12 more 3. Here are the relevant tables and triggers. We have different tables for different sample data types in our application (currently int, long, float, double, Boolean, string). I have shown the int_sample table; the other tables are identical but have a different data type for the value field. Sample records are first class; time records are second class - they only exist to support sample
[jira] Updated: (DERBY-3093) intermittent transaction failure caused by internal duplicate savepoint name, for tirgger
[ https://issues.apache.org/jira/browse/DERBY-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3093: -- Attachment: derby-3093_diff.txt Attached is a patch proposal (derby-3093_diff.txt) for review. Files modified: org.apache.derby.impl.sql.conn.GenericStatementContext.java I changed the way the internal savepoint name isgenerated that should provide unique savepoint names. intermittent transaction failure caused by internal duplicate savepoint name, for tirgger - Key: DERBY-3093 URL: https://issues.apache.org/jira/browse/DERBY-3093 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4 Environment: Java 1.6.0_02 Reporter: Jim Newsham Assignee: James F. Adams Attachments: derby-3093_diff.txt While running our app overnight, performing some intensive database operations (primarily deletes), we experienced a transaction failure, with error message A SAVEPOINT with the passed name already exists in the current transaction. This failure appears to be very intermittent, as I've run the same operation successfully for hours and hours without failure. Some more information: 1. I see that there are four JIRA issues which report the same message (DERBY-2773, DERBY-1457, DERBY-2808, DERBY-2804). I am not sure to what extent if any, the problem I experienced is related to these issues. • At least three of the above JIRA issues are related to triggers. Our transaction failure occurred while performing a delete in a table which has delete triggers. • We aren't using savepoints explicitly. Of course, it can be seen in the stack trace that the trigger operation is setting a savepoint. • One of the JIRA issues mentions exceeding maximum depth of nested triggers. Not sure what a nested trigger is, but the trigger we are performing should not (in theory) cause another trigger event. 2. Here's the stack trace: Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase$3.perform(DerbySampleBase.java:682) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase.performInTransaction(DerbySampleBase.java:2747) ... 7 more Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 18 more Caused by: ERROR 3B501: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.setSavePoint(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.conn.GenericStatementContext.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.fireAfterTriggers(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 12 more 3. Here are the relevant tables and triggers. We have different tables for different sample data types in our
[jira] Updated: (DERBY-3093) intermittent transaction failure caused by internal duplicate savepoint name, for tirgger
[ https://issues.apache.org/jira/browse/DERBY-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-3093: -- Derby Info: [Patch Available] intermittent transaction failure caused by internal duplicate savepoint name, for tirgger - Key: DERBY-3093 URL: https://issues.apache.org/jira/browse/DERBY-3093 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4 Environment: Java 1.6.0_02 Reporter: Jim Newsham Assignee: James F. Adams Attachments: derby-3093_diff.txt While running our app overnight, performing some intensive database operations (primarily deletes), we experienced a transaction failure, with error message A SAVEPOINT with the passed name already exists in the current transaction. This failure appears to be very intermittent, as I've run the same operation successfully for hours and hours without failure. Some more information: 1. I see that there are four JIRA issues which report the same message (DERBY-2773, DERBY-1457, DERBY-2808, DERBY-2804). I am not sure to what extent if any, the problem I experienced is related to these issues. • At least three of the above JIRA issues are related to triggers. Our transaction failure occurred while performing a delete in a table which has delete triggers. • We aren't using savepoints explicitly. Of course, it can be seen in the stack trace that the trigger operation is setting a savepoint. • One of the JIRA issues mentions exceeding maximum depth of nested triggers. Not sure what a nested trigger is, but the trigger we are performing should not (in theory) cause another trigger event. 2. Here's the stack trace: Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase$3.perform(DerbySampleBase.java:682) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase.performInTransaction(DerbySampleBase.java:2747) ... 7 more Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 18 more Caused by: ERROR 3B501: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.setSavePoint(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.conn.GenericStatementContext.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.fireAfterTriggers(Unknown Source) at org.apache.derby.impl.sql.execute.DeleteResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 12 more 3. Here are the relevant tables and triggers. We have different tables for different sample data types in our application (currently int, long, float, double, Boolean, string). I have shown the int_sample table; the other tables are identical but have a different data type for the value field. Sample records are first class; time records are second
[jira] Issue Comment Edited: (DERBY-3093) intermittent transaction failure caused by internal duplicate savepoint name, for tirgger
[ https://issues.apache.org/jira/browse/DERBY-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536446 ] james.f.adams edited comment on DERBY-3093 at 10/20/07 11:37 AM: -- Attached is a patch proposal (derby-3093_diff.txt) for review. Files modified: org.apache.derby.impl.sql.conn.GenericStatementContext.java I changed the way the internal savepoint name isgenerated that should provide unique savepoint names. Derbyall and suites.All ran cleanly. was (Author: james.f.adams): Attached is a patch proposal (derby-3093_diff.txt) for review. Files modified: org.apache.derby.impl.sql.conn.GenericStatementContext.java I changed the way the internal savepoint name isgenerated that should provide unique savepoint names. intermittent transaction failure caused by internal duplicate savepoint name, for tirgger - Key: DERBY-3093 URL: https://issues.apache.org/jira/browse/DERBY-3093 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4 Environment: Java 1.6.0_02 Reporter: Jim Newsham Assignee: James F. Adams Attachments: derby-3093_diff.txt While running our app overnight, performing some intensive database operations (primarily deletes), we experienced a transaction failure, with error message A SAVEPOINT with the passed name already exists in the current transaction. This failure appears to be very intermittent, as I've run the same operation successfully for hours and hours without failure. Some more information: 1. I see that there are four JIRA issues which report the same message (DERBY-2773, DERBY-1457, DERBY-2808, DERBY-2804). I am not sure to what extent if any, the problem I experienced is related to these issues. • At least three of the above JIRA issues are related to triggers. Our transaction failure occurred while performing a delete in a table which has delete triggers. • We aren't using savepoints explicitly. Of course, it can be seen in the stack trace that the trigger operation is setting a savepoint. • One of the JIRA issues mentions exceeding maximum depth of nested triggers. Not sure what a nested trigger is, but the trigger we are performing should not (in theory) cause another trigger event. 2. Here's the stack trace: Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase$3.perform(DerbySampleBase.java:682) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase.performInTransaction(DerbySampleBase.java:2747) ... 7 more Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 18 more Caused by: ERROR 3B501: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.setSavePoint(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.conn.GenericStatementContext.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown Source) at
[jira] Commented: (DERBY-1518) EmbedConnection prepareStatement(String, String[]) throws not implemented (JDBC 3.0)
[ https://issues.apache.org/jira/browse/DERBY-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535794 ] James F. Adams commented on DERBY-1518: --- This functionality appears to have been implemented by DERBY-2631. If so this issue could be closed. EmbedConnection prepareStatement(String, String[]) throws not implemented (JDBC 3.0) -- Key: DERBY-1518 URL: https://issues.apache.org/jira/browse/DERBY-1518 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.1.3.1 Reporter: Brian Bonner Are there any plans to implement this functionality? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3093) intermittent transaction failure caused by internal duplicate savepoint name, for tirgger
[ https://issues.apache.org/jira/browse/DERBY-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535384 ] James F. Adams commented on DERBY-3093: --- In briefly looking into this issue I noticed that the internal savepoint name is created in GenericStatementContext's constructor with the following line of code: internalSavePointName = ISSP + hashCode(); From the javadoc for Object: It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables. As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.) Another method of creating unique names should be implemented. intermittent transaction failure caused by internal duplicate savepoint name, for tirgger - Key: DERBY-3093 URL: https://issues.apache.org/jira/browse/DERBY-3093 Project: Derby Issue Type: Bug Affects Versions: 10.3.1.4 Environment: Java 1.6.0_02 Reporter: Jim Newsham While running our app overnight, performing some intensive database operations (primarily deletes), we experienced a transaction failure, with error message A SAVEPOINT with the passed name already exists in the current transaction. This failure appears to be very intermittent, as I've run the same operation successfully for hours and hours without failure. Some more information: 1. I see that there are four JIRA issues which report the same message (DERBY-2773, DERBY-1457, DERBY-2808, DERBY-2804). I am not sure to what extent if any, the problem I experienced is related to these issues. • At least three of the above JIRA issues are related to triggers. Our transaction failure occurred while performing a delete in a table which has delete triggers. • We aren't using savepoints explicitly. Of course, it can be seen in the stack trace that the trigger operation is setting a savepoint. • One of the JIRA issues mentions exceeding maximum depth of nested triggers. Not sure what a nested trigger is, but the trigger we are performing should not (in theory) cause another trigger event. 2. Here's the stack trace: Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase$3.perform(DerbySampleBase.java:682) at com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase.performInTransaction(DerbySampleBase.java:2747) ... 7 more Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 18 more Caused by: ERROR 3B501: A SAVEPOINT with the passed name already exists in the current transaction. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.setSavePoint(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.conn.GenericStatementContext.setSavePoint(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at
[jira] Commented: (DERBY-2073) Inserting BigDecimal value in PreparedStatement into double column loses fractional digits
[ https://issues.apache.org/jira/browse/DERBY-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522827 ] James F. Adams commented on DERBY-2073: --- This problem appears to only occur with the client driver, the fractional digits are retained when using the embedded driver. Inserting BigDecimal value in PreparedStatement into double column loses fractional digits -- Key: DERBY-2073 URL: https://issues.apache.org/jira/browse/DERBY-2073 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.1.2.1 Environment: windows xp Reporter: Lukasz P Attachments: BigDecimalProblemTester.java Create table with column of type double. Create a prepared statement which inserts value to this column. use preparedStatement#setBigDecimal method of the statement to set value of the column. Execution of such statement succeeds, but actual value in db has no fractional digits. You can use attached test class to reproduce this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-2986) Query involving CASE statement significantly slower in 10.3.1.4 than in 10.2.2.0
[ https://issues.apache.org/jira/browse/DERBY-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams closed DERBY-2986. - Thanks for working on this A B. Query involving CASE statement significantly slower in 10.3.1.4 than in 10.2.2.0 Key: DERBY-2986 URL: https://issues.apache.org/jira/browse/DERBY-2986 Project: Derby Issue Type: Bug Components: Performance Affects Versions: 10.3.1.4 Environment: Windows XP Reporter: James F. Adams Assignee: A B Fix For: 10.3.1.5, 10.4.0.0 Attachments: d2986_notTested_v1.patch, d2986_test.patch A select of a CASE statement that performed acceptably in 10.2.2.0 is very slow in 10.3.1.4 the first time it is executed. The following example ij script: ELAPSEDTIME ON; CREATE table test1(id integer); CREATE table test2(id varchar(10)); SELECT CASE WHEN t.id = 1 THEN 'a' WHEN t.id = 2 THEN 'b' WHEN t.id = 3 THEN 'c' WHEN t.id = 4 THEN 'd' WHEN t.id = 5 THEN 'e' WHEN t.id = 6 THEN 'f' WHEN t.id = 7 THEN 'g' WHEN t.id = 8 THEN 'h' WHEN t.id = 11 THEN 'i' WHEN t.id = 12 THEN 'j' WHEN t.id = 15 THEN 'k' WHEN t.id = 16 THEN 'l' WHEN t.id = 23 THEN 'm' WHEN t.id = 24 THEN 'n' WHEN t.id = 27 THEN 'o' WHEN t.id = 31 THEN 'p' WHEN t.id = 41 THEN 'q' WHEN t.id = 42 THEN 'r' WHEN t.id = 50 THEN 's' ELSE (SELECT t2.id FROM test2 t2 ) END FROM test1 t; When run on 10.2.2.0 the select results in ELAPSED TIME = 187 milliseconds. When run on 10.3.1.4 the select results in ELAPSED TIME = 62281 milliseconds. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2986) Query involving CASE statement significantly slower in 10.3.1.4 than in 10.2.2.0
[ https://issues.apache.org/jira/browse/DERBY-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519352 ] James F. Adams commented on DERBY-2986: --- A B, Thanks for looking into this. I ran derbyAll and suites.All and did not see any errors that I would attribute to this patch. Query involving CASE statement significantly slower in 10.3.1.4 than in 10.2.2.0 Key: DERBY-2986 URL: https://issues.apache.org/jira/browse/DERBY-2986 Project: Derby Issue Type: Bug Components: Performance Affects Versions: 10.3.1.4 Environment: Windows XP Reporter: James F. Adams Attachments: d2986_notTested_v1.patch A select of a CASE statement that performed acceptably in 10.2.2.0 is very slow in 10.3.1.4 the first time it is executed. The following example ij script: ELAPSEDTIME ON; CREATE table test1(id integer); CREATE table test2(id varchar(10)); SELECT CASE WHEN t.id = 1 THEN 'a' WHEN t.id = 2 THEN 'b' WHEN t.id = 3 THEN 'c' WHEN t.id = 4 THEN 'd' WHEN t.id = 5 THEN 'e' WHEN t.id = 6 THEN 'f' WHEN t.id = 7 THEN 'g' WHEN t.id = 8 THEN 'h' WHEN t.id = 11 THEN 'i' WHEN t.id = 12 THEN 'j' WHEN t.id = 15 THEN 'k' WHEN t.id = 16 THEN 'l' WHEN t.id = 23 THEN 'm' WHEN t.id = 24 THEN 'n' WHEN t.id = 27 THEN 'o' WHEN t.id = 31 THEN 'p' WHEN t.id = 41 THEN 'q' WHEN t.id = 42 THEN 'r' WHEN t.id = 50 THEN 's' ELSE (SELECT t2.id FROM test2 t2 ) END FROM test1 t; When run on 10.2.2.0 the select results in ELAPSED TIME = 187 milliseconds. When run on 10.3.1.4 the select results in ELAPSED TIME = 62281 milliseconds. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2986) Query involving CASE statement significantly slower in 10.3.1.4 than in 10.2.2.0
[ https://issues.apache.org/jira/browse/DERBY-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-2986: -- Component/s: Performance Derby Info: [Regression] Query involving CASE statement significantly slower in 10.3.1.4 than in 10.2.2.0 Key: DERBY-2986 URL: https://issues.apache.org/jira/browse/DERBY-2986 Project: Derby Issue Type: Bug Components: Performance Affects Versions: 10.3.1.4 Environment: Windows XP Reporter: James F. Adams A select of a CASE statement that performed acceptably in 10.2.2.0 is very slow in 10.3.1.4 the first time it is executed. The following example ij script: ELAPSEDTIME ON; CREATE table test1(id integer); CREATE table test2(id varchar(10)); SELECT CASE WHEN t.id = 1 THEN 'a' WHEN t.id = 2 THEN 'b' WHEN t.id = 3 THEN 'c' WHEN t.id = 4 THEN 'd' WHEN t.id = 5 THEN 'e' WHEN t.id = 6 THEN 'f' WHEN t.id = 7 THEN 'g' WHEN t.id = 8 THEN 'h' WHEN t.id = 11 THEN 'i' WHEN t.id = 12 THEN 'j' WHEN t.id = 15 THEN 'k' WHEN t.id = 16 THEN 'l' WHEN t.id = 23 THEN 'm' WHEN t.id = 24 THEN 'n' WHEN t.id = 27 THEN 'o' WHEN t.id = 31 THEN 'p' WHEN t.id = 41 THEN 'q' WHEN t.id = 42 THEN 'r' WHEN t.id = 50 THEN 's' ELSE (SELECT t2.id FROM test2 t2 ) END FROM test1 t; When run on 10.2.2.0 the select results in ELAPSED TIME = 187 milliseconds. When run on 10.3.1.4 the select results in ELAPSED TIME = 62281 milliseconds. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2986) Query involving CASE statement significantly slower in 10.3.1.4 than in 10.2.2.0
[ https://issues.apache.org/jira/browse/DERBY-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517416 ] James F. Adams commented on DERBY-2986: --- The following simplified version of the script: ELAPSEDTIME ON; values CASE WHEN 10 = 1 THEN 'a' WHEN 10 = 2 THEN 'b' WHEN 10 = 3 THEN 'c' WHEN 10 = 4 THEN 'd' WHEN 10 = 5 THEN 'e' WHEN 10 = 6 THEN 'f' WHEN 10 = 7 THEN 'g' WHEN 10 = 8 THEN 'h' WHEN 10 = 11 THEN 'i' WHEN 10 = 12 THEN 'j' WHEN 10 = 15 THEN 'k' WHEN 10 = 16 THEN 'l' WHEN 10 = 23 THEN 'm' WHEN 10 = 24 THEN 'n' WHEN 10 = 27 THEN 'o' WHEN 10 = 31 THEN 'p' WHEN 10 = 41 THEN 'q' WHEN 10 = 42 THEN 'r' WHEN 10 = 50 THEN 's' ELSE '*' END; results in: 10.2.2.0 ELAPSED TIME = 297 milliseconds 10.3.1.4 ELAPSED TIME = 52000 milliseconds Query involving CASE statement significantly slower in 10.3.1.4 than in 10.2.2.0 Key: DERBY-2986 URL: https://issues.apache.org/jira/browse/DERBY-2986 Project: Derby Issue Type: Bug Components: Performance Affects Versions: 10.3.1.4 Environment: Windows XP Reporter: James F. Adams A select of a CASE statement that performed acceptably in 10.2.2.0 is very slow in 10.3.1.4 the first time it is executed. The following example ij script: ELAPSEDTIME ON; CREATE table test1(id integer); CREATE table test2(id varchar(10)); SELECT CASE WHEN t.id = 1 THEN 'a' WHEN t.id = 2 THEN 'b' WHEN t.id = 3 THEN 'c' WHEN t.id = 4 THEN 'd' WHEN t.id = 5 THEN 'e' WHEN t.id = 6 THEN 'f' WHEN t.id = 7 THEN 'g' WHEN t.id = 8 THEN 'h' WHEN t.id = 11 THEN 'i' WHEN t.id = 12 THEN 'j' WHEN t.id = 15 THEN 'k' WHEN t.id = 16 THEN 'l' WHEN t.id = 23 THEN 'm' WHEN t.id = 24 THEN 'n' WHEN t.id = 27 THEN 'o' WHEN t.id = 31 THEN 'p' WHEN t.id = 41 THEN 'q' WHEN t.id = 42 THEN 'r' WHEN t.id = 50 THEN 's' ELSE (SELECT t2.id FROM test2 t2 ) END FROM test1 t; When run on 10.2.2.0 the select results in ELAPSED TIME = 187 milliseconds. When run on 10.3.1.4 the select results in ELAPSED TIME = 62281 milliseconds. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-1797) Building toursdb would go a little faster if it used autocommit off mode.
[ https://issues.apache.org/jira/browse/DERBY-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams reassigned DERBY-1797: - Assignee: James F. Adams Building toursdb would go a little faster if it used autocommit off mode. - Key: DERBY-1797 URL: https://issues.apache.org/jira/browse/DERBY-1797 Project: Derby Issue Type: Improvement Components: Build tools, Demos/Scripts Reporter: Daniel John Debrunner Assigned To: James F. Adams Priority: Minor Might also set a good example and remind people to use AUTOCOMMIT OFF when executing similar scripts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1797) Building toursdb would go a little faster if it used autocommit off mode.
[ https://issues.apache.org/jira/browse/DERBY-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-1797: -- Attachment: d1797_v1.stat d1797_v1.patch Attached a simple patch to set autocommit off when creating the schema. Updated the test cannon. Demo suite passes. Building toursdb would go a little faster if it used autocommit off mode. - Key: DERBY-1797 URL: https://issues.apache.org/jira/browse/DERBY-1797 Project: Derby Issue Type: Improvement Components: Build tools, Demos/Scripts Reporter: Daniel John Debrunner Assigned To: James F. Adams Priority: Minor Fix For: 10.3.0.0 Attachments: d1797_v1.patch, d1797_v1.stat Might also set a good example and remind people to use AUTOCOMMIT OFF when executing similar scripts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1797) Building toursdb would go a little faster if it used autocommit off mode.
[ https://issues.apache.org/jira/browse/DERBY-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-1797: -- Derby Info: [Patch Available] Fix Version/s: 10.3.0.0 Building toursdb would go a little faster if it used autocommit off mode. - Key: DERBY-1797 URL: https://issues.apache.org/jira/browse/DERBY-1797 Project: Derby Issue Type: Improvement Components: Build tools, Demos/Scripts Reporter: Daniel John Debrunner Assigned To: James F. Adams Priority: Minor Fix For: 10.3.0.0 Attachments: d1797_v1.patch, d1797_v1.stat Might also set a good example and remind people to use AUTOCOMMIT OFF when executing similar scripts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2605) You can create BOOLEAN columns in 10.3
[ https://issues.apache.org/jira/browse/DERBY-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams resolved DERBY-2605. --- Resolution: Fixed You can create BOOLEAN columns in 10.3 -- Key: DERBY-2605 URL: https://issues.apache.org/jira/browse/DERBY-2605 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.0.0 Reporter: Rick Hillegas Assigned To: James F. Adams Fix For: 10.3.0.0 Attachments: d2605_inc_v1.patch, d2605_v1.patch, d2605_v1.stat, d2605_v2.patch, d2605_v2.stat The work on DERBY-64 seems to have opened up a wormhole by which you can create user tables with BOOLEAN columns. The following script shows how to do this: drop table foo; create table foo as select systemalias from sys.sysaliases with no data; rename column foo.systemalias to boolcol; alter table foo alter column boolcol null; select c.columndatatype from sys.syscolumns c, sys.systables t where t.tableid=c.referenceid and t.tablename='FOO'; insert into foo( boolcol ) values ( 0 ), ( 1 ), ( cast (null as int) ) ; select * from foo; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2605) You can create BOOLEAN columns in 10.3
[ https://issues.apache.org/jira/browse/DERBY-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-2605: -- Attachment: d2605_v2.stat d2605_v2.patch Attached is a new version of a patch for consideration. You can create BOOLEAN columns in 10.3 -- Key: DERBY-2605 URL: https://issues.apache.org/jira/browse/DERBY-2605 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.0.0 Reporter: Rick Hillegas Assigned To: James F. Adams Attachments: d2605_inc_v1.patch, d2605_v1.patch, d2605_v1.stat, d2605_v2.patch, d2605_v2.stat The work on DERBY-64 seems to have opened up a wormhole by which you can create user tables with BOOLEAN columns. The following script shows how to do this: drop table foo; create table foo as select systemalias from sys.sysaliases with no data; rename column foo.systemalias to boolcol; alter table foo alter column boolcol null; select c.columndatatype from sys.syscolumns c, sys.systables t where t.tableid=c.referenceid and t.tablename='FOO'; insert into foo( boolcol ) values ( 0 ), ( 1 ), ( cast (null as int) ) ; select * from foo; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2605) You can create BOOLEAN columns in 10.3
[ https://issues.apache.org/jira/browse/DERBY-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-2605: -- Derby Info: [Patch Available] You can create BOOLEAN columns in 10.3 -- Key: DERBY-2605 URL: https://issues.apache.org/jira/browse/DERBY-2605 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.0.0 Reporter: Rick Hillegas Assigned To: James F. Adams Attachments: d2605_inc_v1.patch, d2605_v1.patch, d2605_v1.stat, d2605_v2.patch, d2605_v2.stat The work on DERBY-64 seems to have opened up a wormhole by which you can create user tables with BOOLEAN columns. The following script shows how to do this: drop table foo; create table foo as select systemalias from sys.sysaliases with no data; rename column foo.systemalias to boolcol; alter table foo alter column boolcol null; select c.columndatatype from sys.syscolumns c, sys.systables t where t.tableid=c.referenceid and t.tablename='FOO'; insert into foo( boolcol ) values ( 0 ), ( 1 ), ( cast (null as int) ) ; select * from foo; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2605) You can create BOOLEAN columns in 10.3
[ https://issues.apache.org/jira/browse/DERBY-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-2605: -- Derby Info: (was: [Patch Available]) You can create BOOLEAN columns in 10.3 -- Key: DERBY-2605 URL: https://issues.apache.org/jira/browse/DERBY-2605 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.0.0 Reporter: Rick Hillegas Assigned To: James F. Adams Attachments: d2605_inc_v1.patch, d2605_v1.patch, d2605_v1.stat The work on DERBY-64 seems to have opened up a wormhole by which you can create user tables with BOOLEAN columns. The following script shows how to do this: drop table foo; create table foo as select systemalias from sys.sysaliases with no data; rename column foo.systemalias to boolcol; alter table foo alter column boolcol null; select c.columndatatype from sys.syscolumns c, sys.systables t where t.tableid=c.referenceid and t.tablename='FOO'; insert into foo( boolcol ) values ( 0 ), ( 1 ), ( cast (null as int) ) ; select * from foo; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2605) You can create BOOLEAN columns in 10.3
[ https://issues.apache.org/jira/browse/DERBY-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495850 ] James F. Adams commented on DERBY-2605: --- A B, I think I prefer your approach. I am updating my patch. I have however found a couple of interesting things with the precision/scale/maximum width check. 1) Given table foo (x double precision), the check fails for: create table bar(y) as select 2.0 * x from foo with no data because dtd.getScale() returns 1 and typeId.getMaximumScale() returns 0. The datat ype of column y is double precision. 2) The check fails for: create table bar as select javaclassname from sys.sysaliases with no data because dtd.getMaximumWidth() returns 2147483647 and typeId.getMaximumMaximumWidth() returns 32700. The data type of javaclassname is LONG VARCHAR. I would expect the maximum length to be 32700. Integer.MAX_VALUE is specified as the maximum length of this column in SYSALIASESRowFactory.java. I do not know if this is a bug or was intentional but the resulting maximum length certainly exceeds the documented value for a LONG VARCHAR. I am doing some more investigation. I should be able to upload an updated patch in a couple of days. You can create BOOLEAN columns in 10.3 -- Key: DERBY-2605 URL: https://issues.apache.org/jira/browse/DERBY-2605 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.0.0 Reporter: Rick Hillegas Assigned To: James F. Adams Attachments: d2605_inc_v1.patch, d2605_v1.patch, d2605_v1.stat The work on DERBY-64 seems to have opened up a wormhole by which you can create user tables with BOOLEAN columns. The following script shows how to do this: drop table foo; create table foo as select systemalias from sys.sysaliases with no data; rename column foo.systemalias to boolcol; alter table foo alter column boolcol null; select c.columndatatype from sys.syscolumns c, sys.systables t where t.tableid=c.referenceid and t.tablename='FOO'; insert into foo( boolcol ) values ( 0 ), ( 1 ), ( cast (null as int) ) ; select * from foo; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2605) You can create BOOLEAN columns in 10.3
[ https://issues.apache.org/jira/browse/DERBY-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams reassigned DERBY-2605: - Assignee: James F. Adams You can create BOOLEAN columns in 10.3 -- Key: DERBY-2605 URL: https://issues.apache.org/jira/browse/DERBY-2605 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.0.0 Reporter: Rick Hillegas Assigned To: James F. Adams The work on DERBY-64 seems to have opened up a wormhole by which you can create user tables with BOOLEAN columns. The following script shows how to do this: drop table foo; create table foo as select systemalias from sys.sysaliases with no data; rename column foo.systemalias to boolcol; alter table foo alter column boolcol null; select c.columndatatype from sys.syscolumns c, sys.systables t where t.tableid=c.referenceid and t.tablename='FOO'; insert into foo( boolcol ) values ( 0 ), ( 1 ), ( cast (null as int) ) ; select * from foo; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2605) You can create BOOLEAN columns in 10.3
[ https://issues.apache.org/jira/browse/DERBY-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-2605: -- Attachment: d2605_v1.stat d2605_v1.patch Attached is a patch that addresses the ability to create columns where the data type of the column is currently for internal use or otherwise not exposed to the user. I added an isInternalTypeId method to TypeId and defined the following types as being for internal use: BOOLEAN NATIONAL CHAR NATIONAL LONGVARCHAR NATIONAL VARCHAR REF TINYINT USERDEFINED NCLOB CreateTableNode was updated to use this method to check the data type of each column. A new message was added. A new test was added. This patch does not address the situation with the VALUES statement desribed by Army. I am wondering if the VALUES statement should even be allowed to create rows with invalid decimal precision. You can create BOOLEAN columns in 10.3 -- Key: DERBY-2605 URL: https://issues.apache.org/jira/browse/DERBY-2605 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.0.0 Reporter: Rick Hillegas Assigned To: James F. Adams Attachments: d2605_v1.patch, d2605_v1.stat The work on DERBY-64 seems to have opened up a wormhole by which you can create user tables with BOOLEAN columns. The following script shows how to do this: drop table foo; create table foo as select systemalias from sys.sysaliases with no data; rename column foo.systemalias to boolcol; alter table foo alter column boolcol null; select c.columndatatype from sys.syscolumns c, sys.systables t where t.tableid=c.referenceid and t.tablename='FOO'; insert into foo( boolcol ) values ( 0 ), ( 1 ), ( cast (null as int) ) ; select * from foo; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2605) You can create BOOLEAN columns in 10.3
[ https://issues.apache.org/jira/browse/DERBY-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-2605: -- Derby Info: [Patch Available] You can create BOOLEAN columns in 10.3 -- Key: DERBY-2605 URL: https://issues.apache.org/jira/browse/DERBY-2605 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.0.0 Reporter: Rick Hillegas Assigned To: James F. Adams Attachments: d2605_v1.patch, d2605_v1.stat The work on DERBY-64 seems to have opened up a wormhole by which you can create user tables with BOOLEAN columns. The following script shows how to do this: drop table foo; create table foo as select systemalias from sys.sysaliases with no data; rename column foo.systemalias to boolcol; alter table foo alter column boolcol null; select c.columndatatype from sys.syscolumns c, sys.systables t where t.tableid=c.referenceid and t.tablename='FOO'; insert into foo( boolcol ) values ( 0 ), ( 1 ), ( cast (null as int) ) ; select * from foo; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-64) Create a table with a query
[ https://issues.apache.org/jira/browse/DERBY-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams reassigned DERBY-64: --- Assignee: (was: James F. Adams) I do not have time to continue to work on this at this time. I am setting the issue to unassigned in case someone else wants to finish the WITH DATA option. Create a table with a query --- Key: DERBY-64 URL: https://issues.apache.org/jira/browse/DERBY-64 Project: Derby Issue Type: New Feature Components: SQL Reporter: Christian d'Heureuse Attachments: Derby64Patch1.txt, Derby64Patch2.txt, Derby64Patch3.txt, Derby64Patch4.txt I suggest to implement a SQL statement to create and fill a table with a query, without having to write the columns definition. e.g.: CREATE TABLE new_table AS SELECT ...; or: SELECT ... INTO new_table FROM ...; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-64) Create a table with a query
[ https://issues.apache.org/jira/browse/DERBY-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465036 ] James F. Adams commented on DERBY-64: - A B, Thank you for reviewing and committing the latest patch. I would like to work on the WITH DATA option. I assume I will need to modify CreateTableConstantAction to load the data obtained via the query expression after the conglomerate is created. I am not at all familiar with this area of the code so any guidance would be greatly appreciated. Create a table with a query --- Key: DERBY-64 URL: https://issues.apache.org/jira/browse/DERBY-64 Project: Derby Issue Type: New Feature Components: SQL Reporter: Christian d'Heureuse Assigned To: James F. Adams Attachments: Derby64Patch1.txt, Derby64Patch2.txt, Derby64Patch3.txt, Derby64Patch4.txt I suggest to implement a SQL statement to create and fill a table with a query, without having to write the columns definition. e.g.: CREATE TABLE new_table AS SELECT ...; or: SELECT ... INTO new_table FROM ...; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-64) Create a table with a query
[ https://issues.apache.org/jira/browse/DERBY-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-64: Attachment: Derby64Patch4.txt Create a table with a query --- Key: DERBY-64 URL: https://issues.apache.org/jira/browse/DERBY-64 Project: Derby Issue Type: New Feature Components: SQL Reporter: Christian d'Heureuse Assigned To: James F. Adams Attachments: Derby64Patch1.txt, Derby64Patch2.txt, Derby64Patch3.txt, Derby64Patch4.txt I suggest to implement a SQL statement to create and fill a table with a query, without having to write the columns definition. e.g.: CREATE TABLE new_table AS SELECT ...; or: SELECT ... INTO new_table FROM ...; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-64) Create a table with a query
[ https://issues.apache.org/jira/browse/DERBY-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-64: Attachment: (was: Derby64Patch4.txt) Create a table with a query --- Key: DERBY-64 URL: https://issues.apache.org/jira/browse/DERBY-64 Project: Derby Issue Type: New Feature Components: SQL Reporter: Christian d'Heureuse Assigned To: James F. Adams Attachments: Derby64Patch1.txt, Derby64Patch2.txt, Derby64Patch3.txt I suggest to implement a SQL statement to create and fill a table with a query, without having to write the columns definition. e.g.: CREATE TABLE new_table AS SELECT ...; or: SELECT ... INTO new_table FROM ...; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-64) Create a table with a query
[ https://issues.apache.org/jira/browse/DERBY-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-64: Attachment: Derby64Patch4.txt Create a table with a query --- Key: DERBY-64 URL: https://issues.apache.org/jira/browse/DERBY-64 Project: Derby Issue Type: New Feature Components: SQL Reporter: Christian d'Heureuse Assigned To: James F. Adams Attachments: Derby64Patch1.txt, Derby64Patch2.txt, Derby64Patch3.txt, Derby64Patch4.txt I suggest to implement a SQL statement to create and fill a table with a query, without having to write the columns definition. e.g.: CREATE TABLE new_table AS SELECT ...; or: SELECT ... INTO new_table FROM ...; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-64) Create a table with a query
[ https://issues.apache.org/jira/browse/DERBY-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463906 ] James F. Adams commented on DERBY-64: - I have attached an updated patch (Derby64Patch4.txt) that should address the comments on my previous effort. The tests have been re-implemented as JUnit tests. I added code to verify that the created tables have the correct column names, types, and nullability. I modified the changes I made to CreateTableNode.java and sqlgrammar.jj so none of the added/modified lines are longer than 80 characters. Create a table with a query --- Key: DERBY-64 URL: https://issues.apache.org/jira/browse/DERBY-64 Project: Derby Issue Type: New Feature Components: SQL Reporter: Christian d'Heureuse Assigned To: James F. Adams Attachments: Derby64Patch1.txt, Derby64Patch2.txt, Derby64Patch3.txt, Derby64Patch4.txt I suggest to implement a SQL statement to create and fill a table with a query, without having to write the columns definition. e.g.: CREATE TABLE new_table AS SELECT ...; or: SELECT ... INTO new_table FROM ...; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-64) Create a table with a query
[ https://issues.apache.org/jira/browse/DERBY-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463775 ] James F. Adams commented on DERBY-64: - A B -- Thanks for reviewing my work. I will convert the tests that I wrote to JUnit tests to be inline with the current testing philosophy. I will add additional tests to verify that the tables were created correctly, including the nullability of the columns. Create a table with a query --- Key: DERBY-64 URL: https://issues.apache.org/jira/browse/DERBY-64 Project: Derby Issue Type: New Feature Components: SQL Reporter: Christian d'Heureuse Assigned To: James F. Adams Attachments: Derby64Patch1.txt, Derby64Patch2.txt, Derby64Patch3.txt I suggest to implement a SQL statement to create and fill a table with a query, without having to write the columns definition. e.g.: CREATE TABLE new_table AS SELECT ...; or: SELECT ... INTO new_table FROM ...; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-64) Create a table with a query
[ https://issues.apache.org/jira/browse/DERBY-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463447 ] James F. Adams commented on DERBY-64: - A B, Yes, I am still planning to create test cases for the the current (NO DATA) functionality. I should be able to have something to contribute by the end of this week. Create a table with a query --- Key: DERBY-64 URL: https://issues.apache.org/jira/browse/DERBY-64 Project: Derby Issue Type: New Feature Components: SQL Reporter: Christian d'Heureuse Assigned To: James F. Adams Attachments: Derby64Patch1.txt, Derby64Patch2.txt I suggest to implement a SQL statement to create and fill a table with a query, without having to write the columns definition. e.g.: CREATE TABLE new_table AS SELECT ...; or: SELECT ... INTO new_table FROM ...; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-64) Create a table with a query
[ https://issues.apache.org/jira/browse/DERBY-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James F. Adams updated DERBY-64: Attachment: Derby64Patch3.txt Create a table with a query --- Key: DERBY-64 URL: https://issues.apache.org/jira/browse/DERBY-64 Project: Derby Issue Type: New Feature Components: SQL Reporter: Christian d'Heureuse Assigned To: James F. Adams Attachments: Derby64Patch1.txt, Derby64Patch2.txt, Derby64Patch3.txt I suggest to implement a SQL statement to create and fill a table with a query, without having to write the columns definition. e.g.: CREATE TABLE new_table AS SELECT ...; or: SELECT ... INTO new_table FROM ...; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-64) Create a table with a query
[ https://issues.apache.org/jira/browse/DERBY-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463457 ] James F. Adams commented on DERBY-64: - I attached a new version of the patch (Derby64Patch3.txt) that adds tests for the functionality provided so far. Create a table with a query --- Key: DERBY-64 URL: https://issues.apache.org/jira/browse/DERBY-64 Project: Derby Issue Type: New Feature Components: SQL Reporter: Christian d'Heureuse Assigned To: James F. Adams Attachments: Derby64Patch1.txt, Derby64Patch2.txt, Derby64Patch3.txt I suggest to implement a SQL statement to create and fill a table with a query, without having to write the columns definition. e.g.: CREATE TABLE new_table AS SELECT ...; or: SELECT ... INTO new_table FROM ...; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-64) Create a table with a query
[ http://issues.apache.org/jira/browse/DERBY-64?page=all ] James F. Adams updated DERBY-64: Attachment: Derby64Patch2.txt I have updated the patch due to numerous changes on the trunk. Hopefully someone will have time to review and comment. Create a table with a query --- Key: DERBY-64 URL: http://issues.apache.org/jira/browse/DERBY-64 Project: Derby Issue Type: New Feature Components: SQL Reporter: Christian d'Heureuse Assigned To: James F. Adams Attachments: Derby64Patch1.txt, Derby64Patch2.txt I suggest to implement a SQL statement to create and fill a table with a query, without having to write the columns definition. e.g.: CREATE TABLE new_table AS SELECT ...; or: SELECT ... INTO new_table FROM ...; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2143) Updated localized messages for Derby 10.2
[ http://issues.apache.org/jira/browse/DERBY-2143?page=comments#action_12456673 ] James F. Adams commented on DERBY-2143: --- There is a syntax error (missing quote character) in NetServlet.java that prevents the trunk from compiling. Updated localized messages for Derby 10.2 - Key: DERBY-2143 URL: http://issues.apache.org/jira/browse/DERBY-2143 Project: Derby Issue Type: Improvement Components: Localization Affects Versions: 10.2.2.0 Reporter: Andrew McIntyre Assigned To: Andrew McIntyre Priority: Minor Fix For: 10.2.2.0, 10.3.0.0 Attachments: derby-2143-refGuide-v01.diff, derby-2143-v1.diff, derby-2143-v2.diff, DERBY2143_misc.diff, DERBY_2143_doc.diff, DERBY_243_miscdoc.zip, rrefsqlj75638.html Update the localized messages that were added during the 10.2 development cycle. Add new localizations for Czech, Hungarian, Polish, and Russian. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-64) Create a table with a query
[ http://issues.apache.org/jira/browse/DERBY-64?page=all ] James F. Adams updated DERBY-64: Attachment: Derby64Patch1.txt I uploaded the patch Derby64Patch1.txt. This is certainly a work in progress and is not complete, but I uploaded it as I have a few questions and could use some guidance. The patch includes the following: SQLState.java and messages.xml were modified to add three messages to flag various errors. These error messages are similar to those used by CREATE VIEW. I was wondering if I should have parameterized the two messages that differ only in the use of TABLE instead of VIEW? sqlgrammer.jj was modified to support the following syntax: CREATE TABLE new_table AS subquery WITH [NO] DATA CreateTableNode.java was modified to define a new init method to take a result column list and a query expression. The bindStatement method was modified to bind the quiery expression and create the table element list from the result column list and the query expression. The current patch does not implement the WITH DATA option. When WITH DATA is specified the table should be populated with the result of the query expression. It is not obvious to me how this should be implemented. Any guideance would be greatly appreciated. Things left to do: Implement the WITH DATA option. Implement tests. Update documentation. Create a table with a query --- Key: DERBY-64 URL: http://issues.apache.org/jira/browse/DERBY-64 Project: Derby Issue Type: New Feature Components: SQL Reporter: Christian d'Heureuse Assigned To: James F. Adams Attachments: Derby64Patch1.txt I suggest to implement a SQL statement to create and fill a table with a query, without having to write the columns definition. e.g.: CREATE TABLE new_table AS SELECT ...; or: SELECT ... INTO new_table FROM ...; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-64) Create a table with a query
[ http://issues.apache.org/jira/browse/DERBY-64?page=all ] James F. Adams updated DERBY-64: Derby Info: [Patch Available] Create a table with a query --- Key: DERBY-64 URL: http://issues.apache.org/jira/browse/DERBY-64 Project: Derby Issue Type: New Feature Components: SQL Reporter: Christian d'Heureuse Assigned To: James F. Adams Attachments: Derby64Patch1.txt I suggest to implement a SQL statement to create and fill a table with a query, without having to write the columns definition. e.g.: CREATE TABLE new_table AS SELECT ...; or: SELECT ... INTO new_table FROM ...; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-64) Create a table with a query
[ http://issues.apache.org/jira/browse/DERBY-64?page=all ] James F. Adams reassigned DERBY-64: --- Assignee: James F. Adams Create a table with a query --- Key: DERBY-64 URL: http://issues.apache.org/jira/browse/DERBY-64 Project: Derby Issue Type: New Feature Components: SQL Reporter: Christian d'Heureuse Assigned To: James F. Adams I suggest to implement a SQL statement to create and fill a table with a query, without having to write the columns definition. e.g.: CREATE TABLE new_table AS SELECT ...; or: SELECT ... INTO new_table FROM ...; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-457) Support for equivalent of Oracle's describe command
[ http://issues.apache.org/jira/browse/DERBY-457?page=comments#action_12442763 ] James F. Adams commented on DERBY-457: -- I believe this can be closed. This functionality appears to be implemented by DERBY-1164. Support for equivalent of Oracle's describe command --- Key: DERBY-457 URL: http://issues.apache.org/jira/browse/DERBY-457 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.0.2.1 Reporter: simmi iyer Priority: Minor Most of the databases provide a descibe command that displays the columns and their data types for a table. Using dblookup for this purpose is too heavy-duty. Dblookup is more like reverse engineering tool i.e. generating schema description from a schema. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (DERBY-183) Parameter names required in CREATE FUNCTION
[ http://issues.apache.org/jira/browse/DERBY-183?page=all ] James F. Adams reopened DERBY-183: -- I found through some additional testing that the previous patch has a problem for some parameter types. I have a re-worked patch that I will attach that resolves this. Parameter names required in CREATE FUNCTION --- Key: DERBY-183 URL: http://issues.apache.org/jira/browse/DERBY-183 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0 Reporter: Jack Klebanoff Assigned To: James F. Adams Priority: Minor Fix For: 10.3.0.0 Attachments: Derby183.patch.txt, Derby183.patch2.txt, Derby183.patch3.txt A statement like create function s2.f2( char(8), integer) returns int language java parameter style java external name 'myclass.mymethod' fails with the message ERROR 42X01: Syntax error: Encountered char at line 1, column 24 However create function s2.f2( p1 char(8), p2 integer) returns int language java parameter style java external name 'myclass.mymethod' is accepted. The Derby documentation (at http://incubator.apache.org/derby/manuals/reference/sqlj27.html#CREATE+PROCEDURE+Statement), the SQL2003 standard, and DB2 all agree that the parameter name is optional. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-183) Parameter names required in CREATE FUNCTION
[ http://issues.apache.org/jira/browse/DERBY-183?page=all ] James F. Adams updated DERBY-183: - Attachment: Derby183.patch4.txt The lookahead in the grammar of my previous patches did not work for some parameter types. I have reworked the lookahead to use syntactic lookahead similar to that used elsewhere in the grammar. I have included an additional test that would have failed with the previous patch. I have run the lang/functions.sql and lang/procedure.java using the various frameworks without error. Parameter names required in CREATE FUNCTION --- Key: DERBY-183 URL: http://issues.apache.org/jira/browse/DERBY-183 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0 Reporter: Jack Klebanoff Assigned To: James F. Adams Priority: Minor Fix For: 10.3.0.0 Attachments: Derby183.patch.txt, Derby183.patch2.txt, Derby183.patch3.txt, Derby183.patch4.txt A statement like create function s2.f2( char(8), integer) returns int language java parameter style java external name 'myclass.mymethod' fails with the message ERROR 42X01: Syntax error: Encountered char at line 1, column 24 However create function s2.f2( p1 char(8), p2 integer) returns int language java parameter style java external name 'myclass.mymethod' is accepted. The Derby documentation (at http://incubator.apache.org/derby/manuals/reference/sqlj27.html#CREATE+PROCEDURE+Statement), the SQL2003 standard, and DB2 all agree that the parameter name is optional. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-183) Parameter names required in CREATE FUNCTION
[ http://issues.apache.org/jira/browse/DERBY-183?page=all ] James F. Adams updated DERBY-183: - Attachment: Derby183.patch3.txt Thanks Bryan for reviewing my patches. Attached is a new patch that modifies the following files and resolves the testing issues: java/engine/org/apache/derby/impl/sql/compile/CreateAliasNode.java java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj java/testing/org/apache/derbyTesting/functionTests/tests/lang/procedure.java java/testing/org/apache/derbyTesting/functionTests/tests/lang/functions.sql java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/jdk16/procedure.out java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/procedure.out java/testing/org/apache/derbyTesting/functionTests/master/functions.out java/testing/org/apache/derbyTesting/functionTests/master/procedure.out java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk16/procedure.out java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/procedure.out java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk14/procedure.out java/testing/org/apache/derbyTesting/functionTests/util/ProcedureTest.java I ran the lang/procedure.java and lang/functions.sql tests using the embedded, DerbyNet, and DerbyNetClient frameworks with Java versions 1.3, 1.4, 1.5, and 1.6 and saw no errors. Parameter names required in CREATE FUNCTION --- Key: DERBY-183 URL: http://issues.apache.org/jira/browse/DERBY-183 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0 Reporter: Jack Klebanoff Assigned To: James F. Adams Priority: Minor Attachments: Derby183.patch.txt, Derby183.patch2.txt, Derby183.patch3.txt A statement like create function s2.f2( char(8), integer) returns int language java parameter style java external name 'myclass.mymethod' fails with the message ERROR 42X01: Syntax error: Encountered char at line 1, column 24 However create function s2.f2( p1 char(8), p2 integer) returns int language java parameter style java external name 'myclass.mymethod' is accepted. The Derby documentation (at http://incubator.apache.org/derby/manuals/reference/sqlj27.html#CREATE+PROCEDURE+Statement), the SQL2003 standard, and DB2 all agree that the parameter name is optional. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-183) Parameter names required in CREATE FUNCTION
[ http://issues.apache.org/jira/browse/DERBY-183?page=comments#action_12441837 ] James F. Adams commented on DERBY-183: -- I have a patch ready that should resolve the remaining test issues. I currently can not upload an attachments. Issue INFRA-984 has been filed by Yip Ng. As soon as this is resolved I will attach the new patch. Parameter names required in CREATE FUNCTION --- Key: DERBY-183 URL: http://issues.apache.org/jira/browse/DERBY-183 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0 Reporter: Jack Klebanoff Assigned To: James F. Adams Priority: Minor Attachments: Derby183.patch.txt, Derby183.patch2.txt A statement like create function s2.f2( char(8), integer) returns int language java parameter style java external name 'myclass.mymethod' fails with the message ERROR 42X01: Syntax error: Encountered char at line 1, column 24 However create function s2.f2( p1 char(8), p2 integer) returns int language java parameter style java external name 'myclass.mymethod' is accepted. The Derby documentation (at http://incubator.apache.org/derby/manuals/reference/sqlj27.html#CREATE+PROCEDURE+Statement), the SQL2003 standard, and DB2 all agree that the parameter name is optional. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-183) Parameter names required in CREATE FUNCTION
[ http://issues.apache.org/jira/browse/DERBY-183?page=all ] James F. Adams updated DERBY-183: - Attachment: Derby183.patch2.txt I have attached an updated patch (Derby183.patch2.txt) that modifies the following files: java/engine/org/apache/derby/impl/sql/compile/CreateAliasNode.java java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj java/testing/org/apache/derbyTesting/functionTests/tests/lang/procedure.java java/testing/org/apache/derbyTesting/functionTests/master/procedure.out java/testing/org/apache/derbyTesting/functionTests/util/ProcedureTest.java java/testing/org/apache/derbyTesting/functionTests/tests/lang/functions.sql java/testing/org/apache/derbyTesting/functionTests/master/functions.out Tests have been added to lang/functions.sql and lang/procedure.java. I added a comment to sqlgrammar.jj to explain the need for the LOOKAHEAD(2). The parameter name is made optional by surrounding its production with []. This changes the grammar from: parameterName = identifier(Limits.MAX_IDENTIFIER_LENGTH, true) typeDescriptor = dataTypeDDL() to: [ parameterName = identifier(Limits.MAX_IDENTIFIER_LENGTH, true) ] typeDescriptor = dataTypeDDL() This results in a choice conflict because certain tokens satisfy both identifier() and dataTypeDDL(). An additional token of lookahead resolves this conflict. This results in: [ LOOKAHEAD(2) parameterName = identifier(Limits.MAX_IDENTIFIER_LENGTH, true) ] typeDescriptor = dataTypeDDL() Expressing this in an alternate form such as: ( parameterName = identifier(Limits.MAX_IDENTIFIER_LENGTH, true) typeDescriptor = dataTypeDDL() ) | typeDescriptor = dataTypeDDL() still results in a choice conflict so I opted for the more compact form. Parameter names required in CREATE FUNCTION --- Key: DERBY-183 URL: http://issues.apache.org/jira/browse/DERBY-183 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0 Reporter: Jack Klebanoff Assigned To: James F. Adams Priority: Minor Attachments: Derby183.patch.txt, Derby183.patch2.txt A statement like create function s2.f2( char(8), integer) returns int language java parameter style java external name 'myclass.mymethod' fails with the message ERROR 42X01: Syntax error: Encountered char at line 1, column 24 However create function s2.f2( p1 char(8), p2 integer) returns int language java parameter style java external name 'myclass.mymethod' is accepted. The Derby documentation (at http://incubator.apache.org/derby/manuals/reference/sqlj27.html#CREATE+PROCEDURE+Statement), the SQL2003 standard, and DB2 all agree that the parameter name is optional. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-183) Parameter names required in CREATE FUNCTION
[ http://issues.apache.org/jira/browse/DERBY-183?page=comments#action_12440773 ] James F. Adams commented on DERBY-183: -- I will create some test cases as suggested and add an explanation why the additional lookahead is needed in the grammar. Parameter names required in CREATE FUNCTION --- Key: DERBY-183 URL: http://issues.apache.org/jira/browse/DERBY-183 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0 Reporter: Jack Klebanoff Assigned To: James F. Adams Priority: Minor Attachments: Derby183.patch.txt A statement like create function s2.f2( char(8), integer) returns int language java parameter style java external name 'myclass.mymethod' fails with the message ERROR 42X01: Syntax error: Encountered char at line 1, column 24 However create function s2.f2( p1 char(8), p2 integer) returns int language java parameter style java external name 'myclass.mymethod' is accepted. The Derby documentation (at http://incubator.apache.org/derby/manuals/reference/sqlj27.html#CREATE+PROCEDURE+Statement), the SQL2003 standard, and DB2 all agree that the parameter name is optional. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1941) CLASSPATH in 2.1 running tests section of test\README.htm should contain derbyrun.jar
CLASSPATH in 2.1 running tests section of test\README.htm should contain derbyrun.jar - Key: DERBY-1941 URL: http://issues.apache.org/jira/browse/DERBY-1941 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6 Reporter: James F. Adams Priority: Minor The section of the file test\README.htm explains how to setup an environment for running Derby tests. It fails to include derbyrun.jar which in required to successfully pass the tools/derbyrunjartest. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1941) CLASSPATH in 2.1 running tests section of test\README.htm should contain derbyrun.jar
[ http://issues.apache.org/jira/browse/DERBY-1941?page=all ] James F. Adams updated DERBY-1941: -- Attachment: readme.patch.txt I have uploaded a patch that modifies the file java/testing/README.htm. CLASSPATH in 2.1 running tests section of test\README.htm should contain derbyrun.jar - Key: DERBY-1941 URL: http://issues.apache.org/jira/browse/DERBY-1941 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6 Reporter: James F. Adams Assigned To: James F. Adams Priority: Minor Attachments: readme.patch.txt The section of the file test\README.htm explains how to setup an environment for running Derby tests. It fails to include derbyrun.jar which in required to successfully pass the tools/derbyrunjartest. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1941) CLASSPATH in 2.1 running tests section of test\README.htm should contain derbyrun.jar
[ http://issues.apache.org/jira/browse/DERBY-1941?page=all ] James F. Adams updated DERBY-1941: -- Derby Info: [Patch Available] CLASSPATH in 2.1 running tests section of test\README.htm should contain derbyrun.jar - Key: DERBY-1941 URL: http://issues.apache.org/jira/browse/DERBY-1941 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6 Reporter: James F. Adams Assigned To: James F. Adams Priority: Minor Attachments: readme.patch.txt The section of the file test\README.htm explains how to setup an environment for running Derby tests. It fails to include derbyrun.jar which in required to successfully pass the tools/derbyrunjartest. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1941) CLASSPATH in QuickStart section of java/testing/README.htm should contain derbyrun.jar
[ http://issues.apache.org/jira/browse/DERBY-1941?page=all ] James F. Adams updated DERBY-1941: -- Summary: CLASSPATH in QuickStart section of java/testing/README.htm should contain derbyrun.jar (was: CLASSPATH in 2.1 running tests section of test\README.htm should contain derbyrun.jar) Description: The section of the file java/testing/README.htm explains how to setup an environment for running Derby tests. It fails to include derbyrun.jar which in required to successfully pass the tools/derbyrunjartest. (was: The section of the file test\README.htm explains how to setup an environment for running Derby tests. It fails to include derbyrun.jar which in required to successfully pass the tools/derbyrunjartest.) CLASSPATH in QuickStart section of java/testing/README.htm should contain derbyrun.jar -- Key: DERBY-1941 URL: http://issues.apache.org/jira/browse/DERBY-1941 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6 Reporter: James F. Adams Assigned To: James F. Adams Priority: Minor Attachments: readme.patch.txt The section of the file java/testing/README.htm explains how to setup an environment for running Derby tests. It fails to include derbyrun.jar which in required to successfully pass the tools/derbyrunjartest. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-183) Parameter names required in CREATE FUNCTION
[ http://issues.apache.org/jira/browse/DERBY-183?page=all ] James F. Adams reassigned DERBY-183: Assignee: James F. Adams Parameter names required in CREATE FUNCTION --- Key: DERBY-183 URL: http://issues.apache.org/jira/browse/DERBY-183 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0 Reporter: Jack Klebanoff Assigned To: James F. Adams Priority: Minor A statement like create function s2.f2( char(8), integer) returns int language java parameter style java external name 'myclass.mymethod' fails with the message ERROR 42X01: Syntax error: Encountered char at line 1, column 24 However create function s2.f2( p1 char(8), p2 integer) returns int language java parameter style java external name 'myclass.mymethod' is accepted. The Derby documentation (at http://incubator.apache.org/derby/manuals/reference/sqlj27.html#CREATE+PROCEDURE+Statement), the SQL2003 standard, and DB2 all agree that the parameter name is optional. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-183) Parameter names required in CREATE FUNCTION
[ http://issues.apache.org/jira/browse/DERBY-183?page=all ] James F. Adams updated DERBY-183: - Derby Info: [Patch Available] Parameter names required in CREATE FUNCTION --- Key: DERBY-183 URL: http://issues.apache.org/jira/browse/DERBY-183 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0 Reporter: Jack Klebanoff Assigned To: James F. Adams Priority: Minor Attachments: Derby183.patch.txt A statement like create function s2.f2( char(8), integer) returns int language java parameter style java external name 'myclass.mymethod' fails with the message ERROR 42X01: Syntax error: Encountered char at line 1, column 24 However create function s2.f2( p1 char(8), p2 integer) returns int language java parameter style java external name 'myclass.mymethod' is accepted. The Derby documentation (at http://incubator.apache.org/derby/manuals/reference/sqlj27.html#CREATE+PROCEDURE+Statement), the SQL2003 standard, and DB2 all agree that the parameter name is optional. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1292) ClassCastException in ClientDriver when using CLOB columns and batch updates
[ http://issues.apache.org/jira/browse/DERBY-1292?page=all ] James F. Adams updated DERBY-1292: -- Attachment: DERBY-1292-v2.diff I have uploaded a new patch for review. I believe it addresses the issues raised with the previous patch. ClassCastException in ClientDriver when using CLOB columns and batch updates Key: DERBY-1292 URL: http://issues.apache.org/jira/browse/DERBY-1292 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.1.2.1 Reporter: Gerald Khin Assigned To: James F. Adams Attachments: DERBY-1292-v2.diff, DERBY-1292.diff java.lang.ClassCastException: java.lang.String at org.apache.derby.client.net.NetStatementRequest.computeProtocolTypesAndLengths(Unknown Source) at org.apache.derby.client.net.NetStatementRequest.buildSQLDTAcommandData(Unknown Source) at org.apache.derby.client.net.NetStatementRequest.writeExecute(Unknown Source) at org.apache.derby.client.net.NetPreparedStatement.writeExecute_(Unknown Source) at org.apache.derby.client.am.PreparedStatement.writeExecute(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatchRequestX(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatchX(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatch(Unknown Source) at CCEBatchUpdateRepro.doInserts(CCEBatchUpdateRepro.java:71) at CCEBatchUpdateRepro.main(CCEBatchUpdateRepro.java:27) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1292) ClassCastException in ClientDriver when using CLOB columns and batch updates
[ http://issues.apache.org/jira/browse/DERBY-1292?page=comments#action_12430315 ] James F. Adams commented on DERBY-1292: --- Thanks for the review Øystein. I have one question about item 6. It appears that the jdbcapi/batchUpdate.java test is skipped when using the DerbyNetClient framework. Should I add the test to both derbynet/perpStmt.java and jdbcapi/batchUpdate? ClassCastException in ClientDriver when using CLOB columns and batch updates Key: DERBY-1292 URL: http://issues.apache.org/jira/browse/DERBY-1292 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.1.2.1 Reporter: Gerald Khin Assigned To: James F. Adams Attachments: DERBY-1292.diff java.lang.ClassCastException: java.lang.String at org.apache.derby.client.net.NetStatementRequest.computeProtocolTypesAndLengths(Unknown Source) at org.apache.derby.client.net.NetStatementRequest.buildSQLDTAcommandData(Unknown Source) at org.apache.derby.client.net.NetStatementRequest.writeExecute(Unknown Source) at org.apache.derby.client.net.NetPreparedStatement.writeExecute_(Unknown Source) at org.apache.derby.client.am.PreparedStatement.writeExecute(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatchRequestX(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatchX(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatch(Unknown Source) at CCEBatchUpdateRepro.doInserts(CCEBatchUpdateRepro.java:71) at CCEBatchUpdateRepro.main(CCEBatchUpdateRepro.java:27) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1292) ClassCastException in ClientDriver when using CLOB columns and batch updates
[ http://issues.apache.org/jira/browse/DERBY-1292?page=comments#action_12429487 ] James F. Adams commented on DERBY-1292: --- The uploaded patch is ready for review. ClassCastException in ClientDriver when using CLOB columns and batch updates Key: DERBY-1292 URL: http://issues.apache.org/jira/browse/DERBY-1292 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.1.2.1 Reporter: Gerald Khin Assigned To: James F. Adams Attachments: DERBY-1292.diff java.lang.ClassCastException: java.lang.String at org.apache.derby.client.net.NetStatementRequest.computeProtocolTypesAndLengths(Unknown Source) at org.apache.derby.client.net.NetStatementRequest.buildSQLDTAcommandData(Unknown Source) at org.apache.derby.client.net.NetStatementRequest.writeExecute(Unknown Source) at org.apache.derby.client.net.NetPreparedStatement.writeExecute_(Unknown Source) at org.apache.derby.client.am.PreparedStatement.writeExecute(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatchRequestX(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatchX(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatch(Unknown Source) at CCEBatchUpdateRepro.doInserts(CCEBatchUpdateRepro.java:71) at CCEBatchUpdateRepro.main(CCEBatchUpdateRepro.java:27) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1292) ClassCastException in ClientDriver when using CLOB columns and batch updates
[ http://issues.apache.org/jira/browse/DERBY-1292?page=all ] James F. Adams updated DERBY-1292: -- Attachment: DERBY-1292.diff The attached patch contains the following: 1) The addition of a copy method to org.apache.derby.client.am.ColumnMetaData. 2) Modifications to org.apache.derby.client.am.PreparedStatement to hold on to a copy of the column meta data for each entry used in batch updates. 3) A test was added to org.apache.derbyTestingfunctionTests.tests.derbynet.prepStmt. I ran derbynet/prepStmt as well as derbyall and did not see any new failures. ClassCastException in ClientDriver when using CLOB columns and batch updates Key: DERBY-1292 URL: http://issues.apache.org/jira/browse/DERBY-1292 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.1.2.1 Reporter: Gerald Khin Assigned To: James F. Adams Attachments: DERBY-1292.diff java.lang.ClassCastException: java.lang.String at org.apache.derby.client.net.NetStatementRequest.computeProtocolTypesAndLengths(Unknown Source) at org.apache.derby.client.net.NetStatementRequest.buildSQLDTAcommandData(Unknown Source) at org.apache.derby.client.net.NetStatementRequest.writeExecute(Unknown Source) at org.apache.derby.client.net.NetPreparedStatement.writeExecute_(Unknown Source) at org.apache.derby.client.am.PreparedStatement.writeExecute(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatchRequestX(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatchX(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatch(Unknown Source) at CCEBatchUpdateRepro.doInserts(CCEBatchUpdateRepro.java:71) at CCEBatchUpdateRepro.main(CCEBatchUpdateRepro.java:27) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1292) ClassCastException in ClientDriver when using CLOB columns and batch updates
[ http://issues.apache.org/jira/browse/DERBY-1292?page=all ] James F. Adams reassigned DERBY-1292: - Assignee: James F. Adams ClassCastException in ClientDriver when using CLOB columns and batch updates Key: DERBY-1292 URL: http://issues.apache.org/jira/browse/DERBY-1292 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.1.2.1 Reporter: Gerald Khin Assigned To: James F. Adams java.lang.ClassCastException: java.lang.String at org.apache.derby.client.net.NetStatementRequest.computeProtocolTypesAndLengths(Unknown Source) at org.apache.derby.client.net.NetStatementRequest.buildSQLDTAcommandData(Unknown Source) at org.apache.derby.client.net.NetStatementRequest.writeExecute(Unknown Source) at org.apache.derby.client.net.NetPreparedStatement.writeExecute_(Unknown Source) at org.apache.derby.client.am.PreparedStatement.writeExecute(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatchRequestX(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatchX(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatch(Unknown Source) at CCEBatchUpdateRepro.doInserts(CCEBatchUpdateRepro.java:71) at CCEBatchUpdateRepro.main(CCEBatchUpdateRepro.java:27) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1292) ClassCastException in ClientDriver when using CLOB columns and batch updates
[ http://issues.apache.org/jira/browse/DERBY-1292?page=comments#action_12423400 ] James F. Adams commented on DERBY-1292: --- Since this is a show stopper for a project that I am working on, I would be happy to work on this. ClassCastException in ClientDriver when using CLOB columns and batch updates Key: DERBY-1292 URL: http://issues.apache.org/jira/browse/DERBY-1292 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.1.2.1 Reporter: Gerald Khin java.lang.ClassCastException: java.lang.String at org.apache.derby.client.net.NetStatementRequest.computeProtocolTypesAndLengths(Unknown Source) at org.apache.derby.client.net.NetStatementRequest.buildSQLDTAcommandData(Unknown Source) at org.apache.derby.client.net.NetStatementRequest.writeExecute(Unknown Source) at org.apache.derby.client.net.NetPreparedStatement.writeExecute_(Unknown Source) at org.apache.derby.client.am.PreparedStatement.writeExecute(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatchRequestX(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatchX(Unknown Source) at org.apache.derby.client.am.PreparedStatement.executeBatch(Unknown Source) at CCEBatchUpdateRepro.doInserts(CCEBatchUpdateRepro.java:71) at CCEBatchUpdateRepro.main(CCEBatchUpdateRepro.java:27) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
