[jira] Commented: (DERBY-4443) Wrap rollback in exception handlers in try-catch
[
https://issues.apache.org/jira/browse/DERBY-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008784#comment-13008784
]
Aaron Digulla commented on DERBY-4443:
--
I think this is beyond the scope of the bug report. Please ask your questions
on stackoverflow.com.
Wrap rollback in exception handlers in try-catch
Key: DERBY-4443
URL: https://issues.apache.org/jira/browse/DERBY-4443
Project: Derby
Issue Type: Bug
Components: Demos/Scripts, Documentation, Eclipse Plug-in, JDBC,
Network Client, Network Server, Replication, Services, SQL, Test, Tools
Affects Versions: 10.5.3.0
Reporter: Aaron Digulla
Labels: derby_triage10_8
Attachments: DERBY-4443.patch
Avoid this pattern everywhere:
}catch(SQLException se){
//issue a rollback on any errors
conn.rollback();
throw se;
}
because an error in rollback will shadow the original exception.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-4443) Wrap rollback in exception handlers in try-catch
[
https://issues.apache.org/jira/browse/DERBY-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007930#comment-13007930
]
Aaron Digulla commented on DERBY-4443:
--
Run the code in a debugger. You will see that the static variable which
contains the current InternalDriver is set in the constructor of
InternalDriver. So you just need to extend the class, call new on your version
and call the system procedure.
Wrap rollback in exception handlers in try-catch
Key: DERBY-4443
URL: https://issues.apache.org/jira/browse/DERBY-4443
Project: Derby
Issue Type: Bug
Components: Demos/Scripts, Documentation, Eclipse Plug-in, JDBC,
Network Client, Network Server, Replication, Services, SQL, Test, Tools
Affects Versions: 10.5.3.0
Reporter: Aaron Digulla
Labels: derby_triage10_8
Attachments: DERBY-4443.patch
Avoid this pattern everywhere:
}catch(SQLException se){
//issue a rollback on any errors
conn.rollback();
throw se;
}
because an error in rollback will shadow the original exception.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-4443) Wrap rollback in exception handlers in try-catch
[
https://issues.apache.org/jira/browse/DERBY-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007637#comment-13007637
]
Aaron Digulla commented on DERBY-4443:
--
The usual solution is to use a mock connection that throws Exceptions when
rollback() is called.
If you look at the code, then you'll see that the connection is created with a
call to getDefaultConn(). This will query the InternalDriver for a connection.
In your tests, extend InternalDriver and override connect() to return a
connection object which throws exceptions for prepareStatement() and rollback():
@Override
public PreparedStatement prepareStatement(String sql) { throw SQLException(
Error in prepareStatement ); }
@Override
public void rollback() { throw SQLException( Error in rollback ); }
Make sure that correct exception is visible outside.
Note that this messes with internal static variables. To fix that, you may need
to create a new driver instance in the tearDown() of your tests.
Wrap rollback in exception handlers in try-catch
Key: DERBY-4443
URL: https://issues.apache.org/jira/browse/DERBY-4443
Project: Derby
Issue Type: Bug
Components: Demos/Scripts, Documentation, Eclipse Plug-in, JDBC,
Network Client, Network Server, Replication, Services, SQL, Test, Tools
Affects Versions: 10.5.3.0
Reporter: Aaron Digulla
Labels: derby_triage10_8
Attachments: DERBY-4443.patch
Avoid this pattern everywhere:
}catch(SQLException se){
//issue a rollback on any errors
conn.rollback();
throw se;
}
because an error in rollback will shadow the original exception.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-4444) Suspected memory leak in Import.importData()
[ https://issues.apache.org/jira/browse/DERBY-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12831645#action_12831645 ] Aaron Digulla commented on DERBY-: -- Did you try with the official releases that I flagged or with a more recent build? Suspected memory leak in Import.importData() Key: DERBY- URL: https://issues.apache.org/jira/browse/DERBY- Project: Derby Issue Type: Bug Affects Versions: 10.4.2.0, 10.5.3.0 Reporter: Aaron Digulla Attachments: ImportData.java, input.dat When calling Import.importData() repeatedly (for example, via SystemProcedures.SYSCS_IMPORT_DATA), then the VM will eventually run out of memory. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-4443) Wrap rollback in exception handlers in try-catch
Wrap rollback in exception handlers in try-catch
Key: DERBY-4443
URL: https://issues.apache.org/jira/browse/DERBY-4443
Project: Derby
Issue Type: Bug
Components: Demos/Scripts, Documentation, Eclipse Plug-in, JDBC,
Network Client, Network Server, Replication, Services, SQL, Store, Test, Tools
Affects Versions: 10.5.3.0
Reporter: Aaron Digulla
Avoid this pattern everywhere:
}catch(SQLException se){
//issue a rollback on any errors
conn.rollback();
throw se;
}
because an error in rollback will shadow the original exception.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4443) Wrap rollback in exception handlers in try-catch
[
https://issues.apache.org/jira/browse/DERBY-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12778286#action_12778286
]
Aaron Digulla commented on DERBY-4443:
--
One place where I've seen this is SystemProcedures. Every method in there uses
this anti-pattern.
Instead of calling rollback directly, a utility function should be defined
which either ignores any exceptions in rollback or, preferred, prints/logs the
exception.
Wrap rollback in exception handlers in try-catch
Key: DERBY-4443
URL: https://issues.apache.org/jira/browse/DERBY-4443
Project: Derby
Issue Type: Bug
Components: Demos/Scripts, Documentation, Eclipse Plug-in, JDBC,
Network Client, Network Server, Replication, Services, SQL, Store, Test, Tools
Affects Versions: 10.5.3.0
Reporter: Aaron Digulla
Avoid this pattern everywhere:
}catch(SQLException se){
//issue a rollback on any errors
conn.rollback();
throw se;
}
because an error in rollback will shadow the original exception.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-4444) Suspected memory leak in Import.importData()
Suspected memory leak in Import.importData() Key: DERBY- URL: https://issues.apache.org/jira/browse/DERBY- Project: Derby Issue Type: Bug Affects Versions: 10.5.3.0, 10.4.2.0 Reporter: Aaron Digulla When calling Import.importData() repeatedly (for example, via SystemProcedures.SYSCS_IMPORT_DATA), then the VM will eventually run out of memory. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4444) Suspected memory leak in Import.importData()
[ https://issues.apache.org/jira/browse/DERBY-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12778304#action_12778304 ] Aaron Digulla commented on DERBY-: -- I tried to profile the issue and it seems that DynamicByteArrayOutputStream is involved but I couldn't nail it down and now, I'm running out of time to pursue the issue further. Maybe someone forgot to call close() on it? Suspected memory leak in Import.importData() Key: DERBY- URL: https://issues.apache.org/jira/browse/DERBY- Project: Derby Issue Type: Bug Affects Versions: 10.4.2.0, 10.5.3.0 Reporter: Aaron Digulla When calling Import.importData() repeatedly (for example, via SystemProcedures.SYSCS_IMPORT_DATA), then the VM will eventually run out of memory. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-4071) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns
[ https://issues.apache.org/jira/browse/DERBY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Digulla closed DERBY-4071. Thanks again for the quick fix! AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns - Key: DERBY-4071 URL: https://issues.apache.org/jira/browse/DERBY-4071 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Assignee: Dag H. Wanvik Fix For: 10.4.2.1, 10.4.3.0, 10.5.0.0, 10.6.0.0 Attachments: derby-4071-10_4.diff, derby-4071-10_4.stat, derby-4071.diff, derby-4071.stat, DerbyTest.java, trialPatch.diff When running a complex query on this table: [code] Create table DEMO.TEST ( CHRCHARACTER(26) , VCHR VARCHAR(25) ) [code] then I get this exception: AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to be the same as col2.getClass() (class SQLVarchar)' was thrown while evaluating an expression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4071) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns
[ https://issues.apache.org/jira/browse/DERBY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680464#action_12680464 ] Aaron Digulla commented on DERBY-4071: -- Thanks for the patch! I've successfully applied it to the official 10.4.2.0 release (only the GroupByNode.java; the tests fail) and my application works now! AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns - Key: DERBY-4071 URL: https://issues.apache.org/jira/browse/DERBY-4071 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Assignee: Dag H. Wanvik Attachments: derby-4071.diff, derby-4071.stat, DerbyTest.java, trialPatch.diff When running a complex query on this table: [code] Create table DEMO.TEST ( CHRCHARACTER(26) , VCHR VARCHAR(25) ) [code] then I get this exception: AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to be the same as col2.getClass() (class SQLVarchar)' was thrown while evaluating an expression. -- 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-4071) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns
[ https://issues.apache.org/jira/browse/DERBY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680464#action_12680464 ] Aaron Digulla edited comment on DERBY-4071 at 3/10/09 6:55 AM: --- Thanks for the patch! I've successfully applied it to the official 10.4.2.0 release (only the GroupByNode.java; the tests fail) and my application works now! Do I have to close this bug as resolved? was (Author: digulla): Thanks for the patch! I've successfully applied it to the official 10.4.2.0 release (only the GroupByNode.java; the tests fail) and my application works now! AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns - Key: DERBY-4071 URL: https://issues.apache.org/jira/browse/DERBY-4071 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Assignee: Dag H. Wanvik Attachments: derby-4071.diff, derby-4071.stat, DerbyTest.java, trialPatch.diff When running a complex query on this table: [code] Create table DEMO.TEST ( CHRCHARACTER(26) , VCHR VARCHAR(25) ) [code] then I get this exception: AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to be the same as col2.getClass() (class SQLVarchar)' was thrown while evaluating an expression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-4089) It should be possible to run unit tests right after ant all
It should be possible to run unit tests right after ant all - Key: DERBY-4089 URL: https://issues.apache.org/jira/browse/DERBY-4089 Project: Derby Issue Type: Improvement Components: Build tools Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Right now, the property derby.junit.classpath is empty by default. There should be an ant target which sets the correct classpath to run all tests after an initial checkout and ant all. The current situation is very confusing to beginners and people who try to build Derby for the first time. For example, when running the tests, I got this exception: java.lang.ClassNotFoundException: org.apache.derbyTesting.junit.EnvTest but that class was there, the file was there, everything was correct. Googling for the error didn't turn anything up, either. It took me a while to believe that build.xml just wouldn't try to setup a classpath for the tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4089) It should be possible to run unit tests right after ant all
[ https://issues.apache.org/jira/browse/DERBY-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680479#action_12680479 ] Aaron Digulla commented on DERBY-4089: -- I suggest to make classes the default (because a novice user will use that first and it fits 95% of the use cases). Experienced developers can then override the default with sane and insane jars (nice name ;), as they see fit because they have the information to make such a decision. It should be possible to run unit tests right after ant all - Key: DERBY-4089 URL: https://issues.apache.org/jira/browse/DERBY-4089 Project: Derby Issue Type: Improvement Components: Build tools Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Right now, the property derby.junit.classpath is empty by default. There should be an ant target which sets the correct classpath to run all tests after an initial checkout and ant all. The current situation is very confusing to beginners and people who try to build Derby for the first time. For example, when running the tests, I got this exception: java.lang.ClassNotFoundException: org.apache.derbyTesting.junit.EnvTest but that class was there, the file was there, everything was correct. Googling for the error didn't turn anything up, either. It took me a while to believe that build.xml just wouldn't try to setup a classpath for the tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4089) It should be possible to run unit tests right after ant all
[ https://issues.apache.org/jira/browse/DERBY-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680518#action_12680518 ] Aaron Digulla commented on DERBY-4089: -- The default should work for most people, that's why it's the default. As soon as you know your way around the source, a developer can define his own property file and override the default. But that simply doesn't work for novices. Also, novices have no commit rights. So I can't see how making life harder for them is going to help solve deeper development issues with Java and the Derby team. :) It should be possible to run unit tests right after ant all - Key: DERBY-4089 URL: https://issues.apache.org/jira/browse/DERBY-4089 Project: Derby Issue Type: Improvement Components: Build tools Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Right now, the property derby.junit.classpath is empty by default. There should be an ant target which sets the correct classpath to run all tests after an initial checkout and ant all. The current situation is very confusing to beginners and people who try to build Derby for the first time. For example, when running the tests, I got this exception: java.lang.ClassNotFoundException: org.apache.derbyTesting.junit.EnvTest but that class was there, the file was there, everything was correct. Googling for the error didn't turn anything up, either. It took me a while to believe that build.xml just wouldn't try to setup a classpath for the tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4071) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns
[ https://issues.apache.org/jira/browse/DERBY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12678671#action_12678671 ] Aaron Digulla commented on DERBY-4071: -- I tried that and I got lots of other, weird errors. I've extended the test case. First of all, you need to give the inner select a name or the SQL won't parse. And after giving it a name, I get an error because S.VCHR is no longer known in the inner select. The final fix is this: SELECT * FROM DEMO.TEST S WHERE S.VCHR IN ( SELECT T1.VCHR FROM DEMO.TEST T1 GROUP BY T1.VCHR HAVING COUNT (T1.VCHR) 1 ) AND S.CHR NOT IN ( select x.a from ( SELECT MAX(T2.CHR) as a, COUNT(T2.VCHR) as b, T2.VCHR as c FROM DEMO.TEST T2 GROUP BY T2.VCHR HAVING COUNT(T2.VCHR) 1 ) as x WHERES.VCHR = x.c ) ... drumroll ... which fails with the same error. AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns - Key: DERBY-4071 URL: https://issues.apache.org/jira/browse/DERBY-4071 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.2.0 Reporter: Aaron Digulla When running a complex query on this table: [code] Create table DEMO.TEST ( CHRCHARACTER(26) , VCHR VARCHAR(25) ) [code] then I get this exception: AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to be the same as col2.getClass() (class SQLVarchar)' was thrown while evaluating an expression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4071) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns
[ https://issues.apache.org/jira/browse/DERBY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Digulla updated DERBY-4071: - Attachment: (was: DerbyTest.java) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns - Key: DERBY-4071 URL: https://issues.apache.org/jira/browse/DERBY-4071 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.2.0 Reporter: Aaron Digulla When running a complex query on this table: [code] Create table DEMO.TEST ( CHRCHARACTER(26) , VCHR VARCHAR(25) ) [code] then I get this exception: AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to be the same as col2.getClass() (class SQLVarchar)' was thrown while evaluating an expression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4071) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns
[ https://issues.apache.org/jira/browse/DERBY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Digulla updated DERBY-4071: - Attachment: DerbyTest.java New version of the test matching the comment Aaron Digulla - 04/Mar/09 02:09 AM AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns - Key: DERBY-4071 URL: https://issues.apache.org/jira/browse/DERBY-4071 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Attachments: DerbyTest.java When running a complex query on this table: [code] Create table DEMO.TEST ( CHRCHARACTER(26) , VCHR VARCHAR(25) ) [code] then I get this exception: AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to be the same as col2.getClass() (class SQLVarchar)' was thrown while evaluating an expression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4074) Allow UPDATE TABLE SET (col1,col2) = (SELECT a,b FROM ...) syntax
[ https://issues.apache.org/jira/browse/DERBY-4074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12678753#action_12678753 ] Aaron Digulla commented on DERBY-4074: -- Okay guys, I've been able to work around most of my test cases but now, I've run into a case where I have about 50 columns. Can someone tell me if this is planned for 10.5 or whether it makes sense for me to try to implement this one? Allow UPDATE TABLE SET (col1,col2) = (SELECT a,b FROM ...) syntax - Key: DERBY-4074 URL: https://issues.apache.org/jira/browse/DERBY-4074 Project: Derby Issue Type: New Feature Reporter: Aaron Digulla Please extend the UPDATE statement to allow this syntax: UPDATE table SET (col1,col2) = (SELECT a,b FROM othertable) This is especially useful when I need to group in the SELECT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4071) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns
[ https://issues.apache.org/jira/browse/DERBY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12678005#action_12678005 ] Aaron Digulla commented on DERBY-4071: -- In this case, I think it's unearthing something. If you look at my example, then I'm only comparing columns of the same type, so why is Derby comparing CHAR and VARCHAR internally? This looks like a column mixup. Or maybe the MAX() casts CHAR to VARCHAR? But why would it do that? Does it also cast INT to LONG? etc. AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns - Key: DERBY-4071 URL: https://issues.apache.org/jira/browse/DERBY-4071 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Attachments: DerbyTest.java When running a complex query on this table: [code] Create table DEMO.TEST ( CHRCHARACTER(26) , VCHR VARCHAR(25) ) [code] then I get this exception: AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to be the same as col2.getClass() (class SQLVarchar)' was thrown while evaluating an expression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4071) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns
[ https://issues.apache.org/jira/browse/DERBY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12676912#action_12676912 ] Aaron Digulla commented on DERBY-4071: -- Good. :) Is it broken in 10.5, too? This might give you a hint: [code] sql = SELECT *\r\n + FROM DEMO.TEST2 S\r\n + WHERE S.VCHR IN (\r\n + SELECT VCHR\r\n + FROM DEMO.TEST2\r\n + GROUP BY VCHR\r\n + HAVING COUNT (VCHR) 1 \r\n + )\r\n + AND S.CHR NOT IN (\r\n + SELECT MAX(T.CHR)\r\n + FROM DEMO.TEST2 T\r\n + WHERES.VCHR = T.VCHR\r\n + GROUP BY T.VCHR\r\n + HAVING COUNT(T.VCHR) 1 \r\n + ); i = dump (sql); assertEquals (1, i); [code] Change: I prefix every CHR column with the table alias. It seems that Derby somehow mixes the columns in the second sub-SELECT. AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns - Key: DERBY-4071 URL: https://issues.apache.org/jira/browse/DERBY-4071 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Attachments: DerbyTest.java When running a complex query on this table: [code] Create table DEMO.TEST ( CHRCHARACTER(26) , VCHR VARCHAR(25) ) [code] then I get this exception: AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to be the same as col2.getClass() (class SQLVarchar)' was thrown while evaluating an expression. -- 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-4071) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns
[ https://issues.apache.org/jira/browse/DERBY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12676912#action_12676912 ] digulla edited comment on DERBY-4071 at 2/26/09 12:23 AM: Good. :) Is it broken in 10.5, too? I've found another version that works: [code] sql = SELECT *\r\n + FROM DEMO.TEST2 S\r\n + WHERE S.VCHR IN (\r\n + SELECT VCHR\r\n + FROM DEMO.TEST2\r\n + GROUP BY VCHR\r\n + HAVING COUNT (VCHR) 1 \r\n + )\r\n + AND S.CHR NOT IN (\r\n + SELECT MAX(T.CHR)\r\n + FROM DEMO.TEST2 T\r\n + WHERES.VCHR = T.VCHR\r\n + GROUP BY T.VCHR\r\n + HAVING COUNT(T.VCHR) 1 \r\n + ); i = dump (sql); assertEquals (1, i); [code] Change: I prefix every CHR column with the table alias. It seems that Derby somehow mixes the columns in the second sub-SELECT. was (Author: digulla): Good. :) Is it broken in 10.5, too? This might give you a hint: [code] sql = SELECT *\r\n + FROM DEMO.TEST2 S\r\n + WHERE S.VCHR IN (\r\n + SELECT VCHR\r\n + FROM DEMO.TEST2\r\n + GROUP BY VCHR\r\n + HAVING COUNT (VCHR) 1 \r\n + )\r\n + AND S.CHR NOT IN (\r\n + SELECT MAX(T.CHR)\r\n + FROM DEMO.TEST2 T\r\n + WHERES.VCHR = T.VCHR\r\n + GROUP BY T.VCHR\r\n + HAVING COUNT(T.VCHR) 1 \r\n + ); i = dump (sql); assertEquals (1, i); [code] Change: I prefix every CHR column with the table alias. It seems that Derby somehow mixes the columns in the second sub-SELECT. AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns - Key: DERBY-4071 URL: https://issues.apache.org/jira/browse/DERBY-4071 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Attachments: DerbyTest.java When running a complex query on this table: [code] Create table DEMO.TEST ( CHRCHARACTER(26) , VCHR VARCHAR(25) ) [code] then I get this exception: AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to be the same as col2.getClass() (class SQLVarchar)' was thrown while evaluating an expression. -- 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-4071) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns
[ https://issues.apache.org/jira/browse/DERBY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12676912#action_12676912 ] digulla edited comment on DERBY-4071 at 2/26/09 12:23 AM: Good. :) Is it broken in 10.5, too? I've found another version that works: [code] sql = SELECT *\r\n + FROM DEMO.TEST2 S\r\n + WHERE S.VCHR IN (\r\n + SELECT VCHR\r\n + FROM DEMO.TEST2\r\n + GROUP BY VCHR\r\n + HAVING COUNT (VCHR) 1 \r\n + )\r\n + AND S.CHR NOT IN (\r\n + // Table S SELECT MAX(T.CHR)\r\n + // Table T FROM DEMO.TEST2 T\r\n + WHERES.VCHR = T.VCHR\r\n + GROUP BY T.VCHR\r\n + HAVING COUNT(T.VCHR) 1 \r\n + ); i = dump (sql); assertEquals (1, i); [code] Change: I prefix every CHR column with the table alias. It seems that Derby somehow mixes the columns in the second sub-SELECT. was (Author: digulla): Good. :) Is it broken in 10.5, too? I've found another version that works: [code] sql = SELECT *\r\n + FROM DEMO.TEST2 S\r\n + WHERE S.VCHR IN (\r\n + SELECT VCHR\r\n + FROM DEMO.TEST2\r\n + GROUP BY VCHR\r\n + HAVING COUNT (VCHR) 1 \r\n + )\r\n + AND S.CHR NOT IN (\r\n + SELECT MAX(T.CHR)\r\n + FROM DEMO.TEST2 T\r\n + WHERES.VCHR = T.VCHR\r\n + GROUP BY T.VCHR\r\n + HAVING COUNT(T.VCHR) 1 \r\n + ); i = dump (sql); assertEquals (1, i); [code] Change: I prefix every CHR column with the table alias. It seems that Derby somehow mixes the columns in the second sub-SELECT. AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns - Key: DERBY-4071 URL: https://issues.apache.org/jira/browse/DERBY-4071 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Attachments: DerbyTest.java When running a complex query on this table: [code] Create table DEMO.TEST ( CHRCHARACTER(26) , VCHR VARCHAR(25) ) [code] then I get this exception: AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to be the same as col2.getClass() (class SQLVarchar)' was thrown while evaluating an expression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4071) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns
[ https://issues.apache.org/jira/browse/DERBY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12676916#action_12676916 ] Aaron Digulla commented on DERBY-4071: -- Update: The quick fix doesn't work with my more complex real table. But it might get you on the right track. AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns - Key: DERBY-4071 URL: https://issues.apache.org/jira/browse/DERBY-4071 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Attachments: DerbyTest.java When running a complex query on this table: [code] Create table DEMO.TEST ( CHRCHARACTER(26) , VCHR VARCHAR(25) ) [code] then I get this exception: AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to be the same as col2.getClass() (class SQLVarchar)' was thrown while evaluating an expression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-4074) Allow UPDATE TABLE SET (col1,col2) = (SELECT a,b FROM ...) syntax
Allow UPDATE TABLE SET (col1,col2) = (SELECT a,b FROM ...) syntax - Key: DERBY-4074 URL: https://issues.apache.org/jira/browse/DERBY-4074 Project: Derby Issue Type: New Feature Reporter: Aaron Digulla Please extend the UPDATE statement to allow this syntax: UPDATE table SET (col1,col2) = (SELECT a,b FROM othertable) This is especially useful when I need to group in the SELECT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4071) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns
[ https://issues.apache.org/jira/browse/DERBY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Digulla updated DERBY-4071: - Attachment: DerbyTest.java Testcase which demonstrates the behavior AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns - Key: DERBY-4071 URL: https://issues.apache.org/jira/browse/DERBY-4071 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Attachments: DerbyTest.java When running a complex query on this table: [code] Create table DEMO.TEST ( CHRCHARACTER(26) , VCHR VARCHAR(25) ) [code] then I get this exception: AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to be the same as col2.getClass() (class SQLVarchar)' was thrown while evaluating an expression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-4071) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns
AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns - Key: DERBY-4071 URL: https://issues.apache.org/jira/browse/DERBY-4071 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Attachments: DerbyTest.java When running a complex query on this table: [code] Create table DEMO.TEST ( CHRCHARACTER(26) , VCHR VARCHAR(25) ) [code] then I get this exception: AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to be the same as col2.getClass() (class SQLVarchar)' was thrown while evaluating an expression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4071) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns
[ https://issues.apache.org/jira/browse/DERBY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12676689#action_12676689 ] Aaron Digulla commented on DERBY-4071: -- This is the query: [code] SELECT * FROM DEMO.TEST S WHERE S.VCHR IN ( SELECT VCHR FROM DEMO.TEST GROUP BY VCHR HAVING COUNT (VCHR) 1 ) AND CHR NOT IN ( SELECT MAX(CHR) FROM DEMO.TEST T WHERES.VCHR = T.VCHR GROUP BY T.VCHR HAVING COUNT(T.VCHR) 1 ) [code] AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns - Key: DERBY-4071 URL: https://issues.apache.org/jira/browse/DERBY-4071 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Attachments: DerbyTest.java When running a complex query on this table: [code] Create table DEMO.TEST ( CHRCHARACTER(26) , VCHR VARCHAR(25) ) [code] then I get this exception: AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to be the same as col2.getClass() (class SQLVarchar)' was thrown while evaluating an expression. -- 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-4071) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns
[ https://issues.apache.org/jira/browse/DERBY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12676689#action_12676689 ] digulla edited comment on DERBY-4071 at 2/25/09 8:13 AM: --- This is the query: [code] SELECT * FROM DEMO.TEST S WHERE S.VCHR IN ( SELECT VCHR FROM DEMO.TEST GROUP BY VCHR HAVING COUNT (VCHR) 1 ) AND CHR NOT IN ( SELECT MAX(CHR) FROM DEMO.TEST T WHERES.VCHR = T.VCHR GROUP BY T.VCHR HAVING COUNT(T.VCHR) 1 ) [code] When you swap the two columns, the errors goes away. My problem: I'm using Derby to replicate a legacy DB2 database in my unit tests so I can create patches for an existing system. Therefore, I'd like to have a solution for Derby 10.4.2.0 instead of swapping the columns. Is there a chance for a quick fix? was (Author: digulla): This is the query: [code] SELECT * FROM DEMO.TEST S WHERE S.VCHR IN ( SELECT VCHR FROM DEMO.TEST GROUP BY VCHR HAVING COUNT (VCHR) 1 ) AND CHR NOT IN ( SELECT MAX(CHR) FROM DEMO.TEST T WHERES.VCHR = T.VCHR GROUP BY T.VCHR HAVING COUNT(T.VCHR) 1 ) [code] AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns - Key: DERBY-4071 URL: https://issues.apache.org/jira/browse/DERBY-4071 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Attachments: DerbyTest.java When running a complex query on this table: [code] Create table DEMO.TEST ( CHRCHARACTER(26) , VCHR VARCHAR(25) ) [code] then I get this exception: AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to be the same as col2.getClass() (class SQLVarchar)' was thrown while evaluating an expression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-4071) AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns
[ https://issues.apache.org/jira/browse/DERBY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12676736#action_12676736 ] Aaron Digulla commented on DERBY-4071: -- I mean: Make VCHR the first column and CHR the second. Just download the test case, copy it into your Derby project and run it. It contains a good case and a bad case. AssertFailure when selecting rows from a table with CHARACTER and VARCHAR columns - Key: DERBY-4071 URL: https://issues.apache.org/jira/browse/DERBY-4071 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.2.0 Reporter: Aaron Digulla Attachments: DerbyTest.java When running a complex query on this table: [code] Create table DEMO.TEST ( CHRCHARACTER(26) , VCHR VARCHAR(25) ) [code] then I get this exception: AssertFailure: ASSERT FAILED col1.getClass() (class ...SQLChar) expected to be the same as col2.getClass() (class SQLVarchar)' was thrown while evaluating an expression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3227) Remove final from all getConnection() methods in EmbeddedDataSource
Remove final from all getConnection() methods in EmbeddedDataSource --- Key: DERBY-3227 URL: https://issues.apache.org/jira/browse/DERBY-3227 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.3.1.4 Reporter: Aaron Digulla Priority: Minor The final modifier makes it impossible to wrap Derby connections in P6Spy, for example. The network ClientDataSource doesn't use final, either. Patch: Replace public final Connection with public Connection two times. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3227) Remove final from all getConnection() methods in EmbeddedDataSource
[ https://issues.apache.org/jira/browse/DERBY-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545480 ] Aaron Digulla commented on DERBY-3227: -- I'm just proposing the most simple solution: Fix the bug at the source. Your proposal is surely possible but: a) it's on my time, b) I have to update it every time you change the API, c) you have no idea about my dependency, so you will make my life miserable by ignorance with every change you make, d) Not even commercial DB drivers make these methods final. I tried with DB2 (which even obfuscates the code), Oracle and MySQL. e) these methods are from the javax.sql.DataSource API which means they can't change anyway. f) All other DataSource implementations in Derby aren't final, either. g) I can no longer rely on the fact that my DataSource extends EmbeddedDataSource (instanceof will fail). Okay, I can live without g). PS: One of the biggest problems in Groovy is that String is final. We had to create our own GString class and we're doing insane stuff to make GString behave like String in every forseeable case (like when you call Java bytecode). Remove final from all getConnection() methods in EmbeddedDataSource --- Key: DERBY-3227 URL: https://issues.apache.org/jira/browse/DERBY-3227 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.3.1.4 Reporter: Aaron Digulla Priority: Minor The final modifier makes it impossible to wrap Derby connections in P6Spy, for example. The network ClientDataSource doesn't use final, either. Patch: Replace public final Connection with public Connection two times. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3083) Network server demands a file called derbynet.jar in classpath
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544794 ] Aaron Digulla commented on DERBY-3083: -- storing these URLs in the system properties (or any global variable) is okay too, because this cannot be exploited from a remote attacker That's an assumption that's hard to prove This is very easy to prove: At the time this happens, the Network Server code has not yet created a socket, so a remote attacker can't connect - q.e.d. These two statements contradict each other,... I'm talking about two completely different things here: One talks about taking the code from the Derby project unmodified and the other talks about a developer building their own Derby server. My argument is that there is no additional vulnerability if you allow any JAR name, it just makes an existing vulnerability more visible (so people who are concerned will know about it and can plan against it). This existing vulnerability can't be closed by enforcing a specific JAR name, so it doesn't matter what the name is and where it comes from. So far, you have failed to come up with a convincing argument why my argument is wrong. If you insist that there might be additional vulnerabilities, list them one by one. Talking grand when we try to find a way to patch a bug is not helping. At the end of the day, the software must work and it must be as secure as we can make it; no more and no less. Network server demands a file called derbynet.jar in classpath Key: DERBY-3083 URL: https://issues.apache.org/jira/browse/DERBY-3083 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.3.1.4 Reporter: Aaron Digulla Attachments: derby-3083-01-requireDerbynet-aa.diff, derby-3083-01-requireDerbynet-ab.diff, derby-716-10-datatypesCollation-aa.diff The network server will not start if the derbynet jar is added under a different name than derbynet.jar to the classpath. This makes it impossible to use it in maven projects where the jar is renamed to derbynet-10.3.1.4.jar. This did work with 10.2.2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3083) Network server demands a file called derbynet.jar in classpath
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544392 ] Aaron Digulla commented on DERBY-3083: -- No, my argument is that there is a vulnerability, thus it is subject to be being exploited. Okay, let me see if we're on the same track here: A Security Manager will do this: It will enforce allowed operations on specific JARs on the classpath. The JARs are not signed and not protected in any way other than their name and path. So Daniel's arguments boils down to this: I enhance security by enforcing the JAR to have a certain name/path. I do not believe this is true. As long as I can add malicious code to the JAR without the SM noticing, enforcing the name will not give additional protection. Therefore, enforcing a specific name will only add a false sense of security which isn't really there. This is even more dangerous than having an unknown vulnerability since people will believe they are safe when they are not. To be as safe as we can possibly be, I suggest that you use Class.getResource() on specific classes which should be on the classpath and strip the package and class from the resulting URL. This will be as safe as the static JAR names (as to my argument above) and it will work for both the case that the JARs have been renamed and that they have been collected in an ueberjar. For the same reasons, storing these URLs in the system properties (or any global variable) is okay too, because this cannot be exploited from a remote attacker and the SM doesn't give any protection against a local attacker anyway. As long as users use the supplied code, they will be perfectly safe as long as no one can modify the classpath when the server is started. If they embed the code in a larger app, they have to think about security themselves; we aren't able to forsee what they might do and therefore, we can't make their code secure for them at this time. Network server demands a file called derbynet.jar in classpath Key: DERBY-3083 URL: https://issues.apache.org/jira/browse/DERBY-3083 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.3.1.4 Reporter: Aaron Digulla Attachments: derby-3083-01-requireDerbynet-aa.diff, derby-3083-01-requireDerbynet-ab.diff, derby-716-10-datatypesCollation-aa.diff The network server will not start if the derbynet jar is added under a different name than derbynet.jar to the classpath. This makes it impossible to use it in maven projects where the jar is renamed to derbynet-10.3.1.4.jar. This did work with 10.2.2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3083) Network server demands a file called derbynet.jar in classpath
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543832 ] Aaron Digulla commented on DERBY-3083: -- To my thinking increasing a security hole in any way is not a good direction to go in. That would mean it is okay for users, who have to rename the JARs, to have no security at all. Your whole argument goes like this: Someone hacks the VM, intercepts the bytecode executor or the JIT, injects malicious code in the right place (after the system properties from the command line have been overwritten by NetworkServerControl.installSecurityManager() and before they are used to install the security policy) and thus takes over the network manager. A possible scenario, I admit. Anyone here who believes this will ever happen? If I gain access to the VM, it would be much more simple to use the debug API to replace the class implementing the SecurityManager or to patch the JARs and restart the service. So ... yes, Ricks approach widens the security window but I fail to see it creating a wider attack vector than what we already have. If you have access to the VM, then you can whack this security scheme to death but my understanding of the whole secuity manager in the Derby context is to make sure it is not possible to inject malicious code from the network side. At the time when the SM is installed, Derby doesn't accept connections, so there is no attack vector at this time. After that, the SM is installed and malicious code from outside is confined within the limits of the SM. If someone has access to the machine, no SM in the world can prevent them to play with the JARs, the classpath or the VM. That is host security and completely outside the scope of Derby. Network server demands a file called derbynet.jar in classpath Key: DERBY-3083 URL: https://issues.apache.org/jira/browse/DERBY-3083 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.3.1.4 Reporter: Aaron Digulla Attachments: derby-716-10-datatypesCollation-aa.diff The network server will not start if the derbynet jar is added under a different name than derbynet.jar to the classpath. This makes it impossible to use it in maven projects where the jar is renamed to derbynet-10.3.1.4.jar. This did work with 10.2.2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3083) Network server demands a file called derbynet.jar in classpath
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540712 ] Aaron Digulla commented on DERBY-3083: -- Rick: This again breaks the idea of least surprise. The network server should not try to install a security manager at all until told so. The first breaking of that rule is what caused the problems in the first place. I suggest that you remove the code which tries to install the SM by default and add new code which is enabled by an option (property or command line). That option should either be yes/no if you can figure out the name of the JAR or it should specify the name of the JAR which contains the preferred SM. If the option is given and no SM can be installed, an exception should be thrown, aborting the program. This would give control to the user instead of involving further black magic which will only lead to a long series of bugs and patches, all because of breaking least surprise again and again. Network server demands a file called derbynet.jar in classpath Key: DERBY-3083 URL: https://issues.apache.org/jira/browse/DERBY-3083 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.3.1.4 Reporter: Aaron Digulla Attachments: derby-716-10-datatypesCollation-aa.diff The network server will not start if the derbynet jar is added under a different name than derbynet.jar to the classpath. This makes it impossible to use it in maven projects where the jar is renamed to derbynet-10.3.1.4.jar. This did work with 10.2.2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3083) Network server demands a file called derbynet.jar in classpath
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540856 ] Aaron Digulla commented on DERBY-3083: -- Well, I've used tons of Java software (probably everything kind except for applets) and Derby was the first one to have a Security Manager, so in my case running into one violated the rule least surprises. OTOH, I know perfectly well that a misconfigured network server compromises the security of my computer (they all do, that's common knowledge even if most people actively ignore this simple fact). Therefore, a network server which is secure also violates the rule. So it is an attempt to make the world better on your part but it certainly breaks the least surprise rule unless you can make it work even when I do strange things like renaming the JAR, repackaging everything in an ueberjar and the like. If you really, absolutely need to have your SM, make it fail gracefully (if DerbyNet can't install it, print a warning and go on) or ask the user to enable it with an option if they need/want it. Otherwise, you will annoy 90% of the users of your code: 10% know more about security than you do and they do it differently; trying to teach them won't work 80% don't know and don't care and they hate you for making their lives unnecessary complex (a.k.a what do I need that stupid virus scanner for? Open that proxy already! OWN3Z.COM wants to install TakeOver.EXE? OK!) Which leaves 10% who don't know and care enough to learn how to secure their system ;-) I'm in the first 10%, by the way: For my JUnit tests, I just need an option to bind the server to 127.0.0.1 and no SM. Network server demands a file called derbynet.jar in classpath Key: DERBY-3083 URL: https://issues.apache.org/jira/browse/DERBY-3083 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.3.1.4 Reporter: Aaron Digulla Attachments: derby-716-10-datatypesCollation-aa.diff The network server will not start if the derbynet jar is added under a different name than derbynet.jar to the classpath. This makes it impossible to use it in maven projects where the jar is renamed to derbynet-10.3.1.4.jar. This did work with 10.2.2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3083) Network server demands a file called derbynet.jar in classpath
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533642 ] Aaron Digulla commented on DERBY-3083: -- Does any documentation indicate that it's *not* ok to change the JAR name? :-) This is Java after all and I'm used that I can use what I can put on the classpath. Moreover, when you use Maven, then the JAR names must include the version number. So this change makes it impossible to use Derby with Maven. I'm using Derby extensively to replace a real DB2 for my test cases and I couldn't care less about a security policy. It's nice to have one shipped with the product but I fail to see the advantage to make it the *default*. Network server demands a file called derbynet.jar in classpath Key: DERBY-3083 URL: https://issues.apache.org/jira/browse/DERBY-3083 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.3.1.4 Reporter: Aaron Digulla The network server will not start if the derbynet jar is added under a different name than derbynet.jar to the classpath. This makes it impossible to use it in maven projects where the jar is renamed to derbynet-10.3.1.4.jar. This did work with 10.2.2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3083) Network server demands a file called derbynet.jar in classpath
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529028 ] Aaron Digulla commented on DERBY-3083: -- Thanks for the workaround. -noSecurityManager works for me, too. In that case, the security manager should be fixed not to rely on a fix jar name :-) What happens when I patch the JAR or feed Java a completely different JAR as derbynet.jar? Network server demands a file called derbynet.jar in classpath Key: DERBY-3083 URL: https://issues.apache.org/jira/browse/DERBY-3083 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.3.1.4 Reporter: Aaron Digulla The network server will not start if the derbynet jar is added under a different name than derbynet.jar to the classpath. This makes it impossible to use it in maven projects where the jar is renamed to derbynet-10.3.1.4.jar. This did work with 10.2.2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3083) Network server demands a file called derbynet.jar in classpath
Network server demands a file called derbynet.jar in classpath Key: DERBY-3083 URL: https://issues.apache.org/jira/browse/DERBY-3083 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.3.1.4 Reporter: Aaron Digulla The network server will not start if the derbynet jar is added under a different name than derbynet.jar to the classpath. This makes it impossible to use it in maven projects where the jar is renamed to derbynet-10.3.1.4.jar. This did work with 10.2.2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2888) Useless error message during import: Invalid character string format for type INTEGER.
[
https://issues.apache.org/jira/browse/DERBY-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520352
]
Aaron Digulla commented on DERBY-2888:
--
Why isn't this a bug? Derby throws an exception that I can't handle and I have
no way to fix the underlying problem. Is there a workaround that I could use?
Useless error message during import: Invalid character string format for type
INTEGER.
--
Key: DERBY-2888
URL: https://issues.apache.org/jira/browse/DERBY-2888
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.2.2.0
Reporter: Aaron Digulla
Priority: Minor
Attachments: BUG1.dbe, BUG1.ddl
When you try to import the attached data file into derby using
SYSCS_UTIL.SYSCS_IMPORT_DATA('DERBY', 'BUG1', null, null, 'bug1.dbe', ';',
'', 'Cp1252', 1), you get the error: Invalid character string format for
type INTEGER.' was thrown while evaluating an expression.
If a table has many columns and many rows are imported, it is impossible to
figure out where the error is in the input file. Please provide the column
name and the line number in the error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2888) Useless error message during import: Invalid character string format for type INTEGER.
[
https://issues.apache.org/jira/browse/DERBY-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520368
]
Aaron Digulla commented on DERBY-2888:
--
Sorry, but I mixed that up. 2193 was to get the line number (which is fixed).
This bug here is specifically to get the column name. So it's not a duplicate.
I was specifically asked in 2193 to open a new bug (- this one here).
Useless error message during import: Invalid character string format for type
INTEGER.
--
Key: DERBY-2888
URL: https://issues.apache.org/jira/browse/DERBY-2888
Project: Derby
Issue Type: Improvement
Components: Tools
Affects Versions: 10.2.2.0
Reporter: Aaron Digulla
Priority: Minor
Attachments: BUG1.dbe, BUG1.ddl
When you try to import the attached data file into derby using
SYSCS_UTIL.SYSCS_IMPORT_DATA('DERBY', 'BUG1', null, null, 'bug1.dbe', ';',
'', 'Cp1252', 1), you get the error: Invalid character string format for
type INTEGER.' was thrown while evaluating an expression.
If a table has many columns and many rows are imported, it is impossible to
figure out where the error is in the input file. Please provide the column
name and the line number in the error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2944) Derby doesn't allow more than one instance per VM
[ https://issues.apache.org/jira/browse/DERBY-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517750 ] Aaron Digulla commented on DERBY-2944: -- None. I just wanted to know if this was allowed. I'll pass the information on. Thank you. Derby doesn't allow more than one instance per VM - Key: DERBY-2944 URL: https://issues.apache.org/jira/browse/DERBY-2944 Project: Derby Issue Type: Bug Components: Miscellaneous Affects Versions: 10.2.2.0 Reporter: Aaron Digulla If you have an IDE or a DB tool, you cannot dynamically load/unload the embedded derby driver. In Eclipse BIRT, this created the following situation: The examples use Derby 10.1. My application uses 10.2. I can't switch between the examples and the reports in my application without restarting Eclipse and patching the Derby plugin. It would be great if you could add a method which we could call to cleanup the embedded driver so we can throw the classloader away and load another instance of Derby. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-2944) Derby doesn't allow more than one instance per VM
[ https://issues.apache.org/jira/browse/DERBY-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Digulla closed DERBY-2944. Resolution: Fixed Fix Version/s: 10.2.2.0 My question has been answered. Derby doesn't allow more than one instance per VM - Key: DERBY-2944 URL: https://issues.apache.org/jira/browse/DERBY-2944 Project: Derby Issue Type: Bug Components: Miscellaneous Affects Versions: 10.2.2.0 Reporter: Aaron Digulla Fix For: 10.2.2.0 If you have an IDE or a DB tool, you cannot dynamically load/unload the embedded derby driver. In Eclipse BIRT, this created the following situation: The examples use Derby 10.1. My application uses 10.2. I can't switch between the examples and the reports in my application without restarting Eclipse and patching the Derby plugin. It would be great if you could add a method which we could call to cleanup the embedded driver so we can throw the classloader away and load another instance of Derby. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2944) Derby doesn't allow more than one instance per VM
Derby doesn't allow more than one instance per VM - Key: DERBY-2944 URL: https://issues.apache.org/jira/browse/DERBY-2944 Project: Derby Issue Type: Bug Components: Miscellaneous Affects Versions: 10.2.2.0 Reporter: Aaron Digulla If you have an IDE or a DB tool, you cannot dynamically load/unload the embedded derby driver. In Eclipse BIRT, this created the following situation: The examples use Derby 10.1. My application uses 10.2. I can't switch between the examples and the reports in my application without restarting Eclipse and patching the Derby plugin. It would be great if you could add a method which we could call to cleanup the embedded driver so we can throw the classloader away and load another instance of Derby. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2944) Derby doesn't allow more than one instance per VM
[ https://issues.apache.org/jira/browse/DERBY-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513363 ] Aaron Digulla commented on DERBY-2944: -- How about running two versions of Derby in two classloaders in the same VM? Derby doesn't allow more than one instance per VM - Key: DERBY-2944 URL: https://issues.apache.org/jira/browse/DERBY-2944 Project: Derby Issue Type: Bug Components: Miscellaneous Affects Versions: 10.2.2.0 Reporter: Aaron Digulla If you have an IDE or a DB tool, you cannot dynamically load/unload the embedded derby driver. In Eclipse BIRT, this created the following situation: The examples use Derby 10.1. My application uses 10.2. I can't switch between the examples and the reports in my application without restarting Eclipse and patching the Derby plugin. It would be great if you could add a method which we could call to cleanup the embedded driver so we can throw the classloader away and load another instance of Derby. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2888) Useless error message during import: Invalid character string format for type INTEGER.
Useless error message during import: Invalid character string format for type
INTEGER.
--
Key: DERBY-2888
URL: https://issues.apache.org/jira/browse/DERBY-2888
Project: Derby
Issue Type: Bug
Components: Tools
Affects Versions: 10.2.2.0
Reporter: Aaron Digulla
Priority: Minor
Attachments: BUG1.ddl
When you try to import the attached data file into derby using
SYSCS_UTIL.SYSCS_IMPORT_DATA('DERBY', 'BUG1', null, null, 'bug1.dbe', ';', '',
'Cp1252', 1), you get the error: Invalid character string format for type
INTEGER.' was thrown while evaluating an expression.
If a table has many columns and many rows are imported, it is impossible to
figure out where the error is in the input file. Please provide the column name
and the line number in the error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2888) Useless error message during import: Invalid character string format for type INTEGER.
[
https://issues.apache.org/jira/browse/DERBY-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Digulla updated DERBY-2888:
-
Attachment: BUG1.dbe
Data file which contains an integer enclosed in quotes.
Useless error message during import: Invalid character string format for type
INTEGER.
--
Key: DERBY-2888
URL: https://issues.apache.org/jira/browse/DERBY-2888
Project: Derby
Issue Type: Bug
Components: Tools
Affects Versions: 10.2.2.0
Reporter: Aaron Digulla
Priority: Minor
Attachments: BUG1.dbe, BUG1.ddl
When you try to import the attached data file into derby using
SYSCS_UTIL.SYSCS_IMPORT_DATA('DERBY', 'BUG1', null, null, 'bug1.dbe', ';',
'', 'Cp1252', 1), you get the error: Invalid character string format for
type INTEGER.' was thrown while evaluating an expression.
If a table has many columns and many rows are imported, it is impossible to
figure out where the error is in the input file. Please provide the column
name and the line number in the error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2888) Useless error message during import: Invalid character string format for type INTEGER.
[
https://issues.apache.org/jira/browse/DERBY-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Digulla updated DERBY-2888:
-
Attachment: BUG1.ddl
Table definition
Useless error message during import: Invalid character string format for type
INTEGER.
--
Key: DERBY-2888
URL: https://issues.apache.org/jira/browse/DERBY-2888
Project: Derby
Issue Type: Bug
Components: Tools
Affects Versions: 10.2.2.0
Reporter: Aaron Digulla
Priority: Minor
Attachments: BUG1.dbe, BUG1.ddl
When you try to import the attached data file into derby using
SYSCS_UTIL.SYSCS_IMPORT_DATA('DERBY', 'BUG1', null, null, 'bug1.dbe', ';',
'', 'Cp1252', 1), you get the error: Invalid character string format for
type INTEGER.' was thrown while evaluating an expression.
If a table has many columns and many rows are imported, it is impossible to
figure out where the error is in the input file. Please provide the column
name and the line number in the error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2888) Useless error message during import: Invalid character string format for type INTEGER.
[
https://issues.apache.org/jira/browse/DERBY-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Digulla updated DERBY-2888:
-
Attachment: (was: BUG1.ddl)
Useless error message during import: Invalid character string format for type
INTEGER.
--
Key: DERBY-2888
URL: https://issues.apache.org/jira/browse/DERBY-2888
Project: Derby
Issue Type: Bug
Components: Tools
Affects Versions: 10.2.2.0
Reporter: Aaron Digulla
Priority: Minor
Attachments: BUG1.dbe, BUG1.ddl
When you try to import the attached data file into derby using
SYSCS_UTIL.SYSCS_IMPORT_DATA('DERBY', 'BUG1', null, null, 'bug1.dbe', ';',
'', 'Cp1252', 1), you get the error: Invalid character string format for
type INTEGER.' was thrown while evaluating an expression.
If a table has many columns and many rows are imported, it is impossible to
figure out where the error is in the input file. Please provide the column
name and the line number in the error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2888) Useless error message during import: Invalid character string format for type INTEGER.
[
https://issues.apache.org/jira/browse/DERBY-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Digulla updated DERBY-2888:
-
Comment: was deleted
Useless error message during import: Invalid character string format for type
INTEGER.
--
Key: DERBY-2888
URL: https://issues.apache.org/jira/browse/DERBY-2888
Project: Derby
Issue Type: Bug
Components: Tools
Affects Versions: 10.2.2.0
Reporter: Aaron Digulla
Priority: Minor
Attachments: BUG1.dbe, BUG1.ddl
When you try to import the attached data file into derby using
SYSCS_UTIL.SYSCS_IMPORT_DATA('DERBY', 'BUG1', null, null, 'bug1.dbe', ';',
'', 'Cp1252', 1), you get the error: Invalid character string format for
type INTEGER.' was thrown while evaluating an expression.
If a table has many columns and many rows are imported, it is impossible to
figure out where the error is in the input file. Please provide the column
name and the line number in the error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2888) Useless error message during import: Invalid character string format for type INTEGER.
[
https://issues.apache.org/jira/browse/DERBY-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Digulla updated DERBY-2888:
-
Attachment: (was: BUG1.dbe)
Useless error message during import: Invalid character string format for type
INTEGER.
--
Key: DERBY-2888
URL: https://issues.apache.org/jira/browse/DERBY-2888
Project: Derby
Issue Type: Bug
Components: Tools
Affects Versions: 10.2.2.0
Reporter: Aaron Digulla
Priority: Minor
Attachments: BUG1.ddl
When you try to import the attached data file into derby using
SYSCS_UTIL.SYSCS_IMPORT_DATA('DERBY', 'BUG1', null, null, 'bug1.dbe', ';',
'', 'Cp1252', 1), you get the error: Invalid character string format for
type INTEGER.' was thrown while evaluating an expression.
If a table has many columns and many rows are imported, it is impossible to
figure out where the error is in the input file. Please provide the column
name and the line number in the error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2888) Useless error message during import: Invalid character string format for type INTEGER.
[
https://issues.apache.org/jira/browse/DERBY-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Digulla updated DERBY-2888:
-
Attachment: BUG1.dbe
Import file which contains a number that is too large for integer.
Useless error message during import: Invalid character string format for type
INTEGER.
--
Key: DERBY-2888
URL: https://issues.apache.org/jira/browse/DERBY-2888
Project: Derby
Issue Type: Bug
Components: Tools
Affects Versions: 10.2.2.0
Reporter: Aaron Digulla
Priority: Minor
Attachments: BUG1.dbe, BUG1.ddl
When you try to import the attached data file into derby using
SYSCS_UTIL.SYSCS_IMPORT_DATA('DERBY', 'BUG1', null, null, 'bug1.dbe', ';',
'', 'Cp1252', 1), you get the error: Invalid character string format for
type INTEGER.' was thrown while evaluating an expression.
If a table has many columns and many rows are imported, it is impossible to
figure out where the error is in the input file. Please provide the column
name and the line number in the error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2888) Useless error message during import: Invalid character string format for type INTEGER.
[
https://issues.apache.org/jira/browse/DERBY-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Digulla updated DERBY-2888:
-
Comment: was deleted
Useless error message during import: Invalid character string format for type
INTEGER.
--
Key: DERBY-2888
URL: https://issues.apache.org/jira/browse/DERBY-2888
Project: Derby
Issue Type: Bug
Components: Tools
Affects Versions: 10.2.2.0
Reporter: Aaron Digulla
Priority: Minor
Attachments: BUG1.dbe, BUG1.ddl
When you try to import the attached data file into derby using
SYSCS_UTIL.SYSCS_IMPORT_DATA('DERBY', 'BUG1', null, null, 'bug1.dbe', ';',
'', 'Cp1252', 1), you get the error: Invalid character string format for
type INTEGER.' was thrown while evaluating an expression.
If a table has many columns and many rows are imported, it is impossible to
figure out where the error is in the input file. Please provide the column
name and the line number in the error message.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2193) [import] ERROR 38000: StringIndexOutOfBoundsException was thrown while evaluating an expression.
[ https://issues.apache.org/jira/browse/DERBY-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488769 ] Aaron Digulla commented on DERBY-2193: -- Thanks, that looks much better. Here are a few more cases which can cause problems: - No newline at the end of the file - When you have a table with N columns and an INT column at the end and the import file has N+1 columns, the import tries to assign the last two columns to the INT column - If you have illegal characters in INT columns (like a or .) In all these cases, you'll only get an error that a column couldn't be parsed but not *which* column. Can you add the column number or name to the error message, too? Or should I open a new JIRA for this? If you want that in a new JIRA, then this one can be closed. [import] ERROR 38000: StringIndexOutOfBoundsException was thrown while evaluating an expression. Key: DERBY-2193 URL: https://issues.apache.org/jira/browse/DERBY-2193 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.2.1.6 Reporter: Aaron Digulla Attachments: derby-2193-01.diff, derby-2193-02-rev2.diff, derby-2193-02.diff, derby-2193-script.jar During import of a file, I get this error: ERROR 38000: The exception 'java.sql.SQLException: Java exception: 'java.lang.StringIndexOutOfBoundsException: String index out of range: -14'.' was thrown while evaluating an expression. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.error.StandardException.unexpectedUserException(Unknown Source) at org.apache.derby.impl.services.reflect.ReflectMethod.invoke(Unknown Source) at org.apache.derby.impl.sql.execute.CallStatementResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) ... How am I supposed to find what's wrong in a big import? :-) It should at least mention the file which I was importing, the row and the column when the error occurred. After printing the whole exceptions chain, I got these additional two: ERROR XJ001: Java exception: 'java.lang.StringIndexOutOfBoundsException: String index out of range: -14'. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.error.StandardException.plainWrapException(Unknown Source) at org.apache.derby.impl.load.LoadError.unexpectedError(Unknown Source) at org.apache.derby.impl.load.ImportAbstract.next(Unknown Source) at org.apache.derby.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.NoPutResultSetImpl.getNextRowFromRowSource(Unknown Source) at org.apache.derby.impl.store.access.heap.HeapController.load(Unknown Source) at org.apache.derby.impl.store.access.heap.Heap.load(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.loadConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.recreateAndLoadConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.createAndLoadConglomerate(Unknown Source) at org.apache.derby.impl.sql.execute.InsertResultSet.bulkInsertCore(Unknown Source) at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at org.apache.derby.impl.load.Import.performImport(Unknown Source) at org.apache.derby.impl.load.Import.importData(Unknown Source) at org.apache.derby.catalog.SystemProcedures.SYSCS_IMPORT_DATA(Unknown Source) at org.apache.derby.exe.ac07170079x010fx9622xb7bax0011a6e80.g0(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at
[jira] Commented: (DERBY-2193) [import] ERROR 38000: StringIndexOutOfBoundsException was thrown while evaluating an expression.
[ https://issues.apache.org/jira/browse/DERBY-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488008 ] Aaron Digulla commented on DERBY-2193: -- This resolves the minor issue in my case. My main problem is that I get no information where an error during an import occurred. The exception should contain at least the filename and the line number. If that is not available, please throw a wrapped exception with the whole record in getNextRowCore(). [import] ERROR 38000: StringIndexOutOfBoundsException was thrown while evaluating an expression. Key: DERBY-2193 URL: https://issues.apache.org/jira/browse/DERBY-2193 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.2.1.6 Reporter: Aaron Digulla Attachments: derby-2193-01.diff, derby-2193-script.jar During import of a file, I get this error: ERROR 38000: The exception 'java.sql.SQLException: Java exception: 'java.lang.StringIndexOutOfBoundsException: String index out of range: -14'.' was thrown while evaluating an expression. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.error.StandardException.unexpectedUserException(Unknown Source) at org.apache.derby.impl.services.reflect.ReflectMethod.invoke(Unknown Source) at org.apache.derby.impl.sql.execute.CallStatementResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) ... How am I supposed to find what's wrong in a big import? :-) It should at least mention the file which I was importing, the row and the column when the error occurred. After printing the whole exceptions chain, I got these additional two: ERROR XJ001: Java exception: 'java.lang.StringIndexOutOfBoundsException: String index out of range: -14'. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.error.StandardException.plainWrapException(Unknown Source) at org.apache.derby.impl.load.LoadError.unexpectedError(Unknown Source) at org.apache.derby.impl.load.ImportAbstract.next(Unknown Source) at org.apache.derby.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.NoPutResultSetImpl.getNextRowFromRowSource(Unknown Source) at org.apache.derby.impl.store.access.heap.HeapController.load(Unknown Source) at org.apache.derby.impl.store.access.heap.Heap.load(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.loadConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.recreateAndLoadConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.createAndLoadConglomerate(Unknown Source) at org.apache.derby.impl.sql.execute.InsertResultSet.bulkInsertCore(Unknown Source) at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at org.apache.derby.impl.load.Import.performImport(Unknown Source) at org.apache.derby.impl.load.Import.importData(Unknown Source) at org.apache.derby.catalog.SystemProcedures.SYSCS_IMPORT_DATA(Unknown Source) at org.apache.derby.exe.ac07170079x010fx9622xb7bax0011a6e80.g0(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.derby.impl.services.reflect.ReflectMethod.invoke(Unknown Source) at org.apache.derby.impl.sql.execute.CallStatementResultSet.open(Unknown Source) at
[jira] Created: (DERBY-2193) [import] ERROR 38000: StringIndexOutOfBoundsException was thrown while evaluating an expression.
[import] ERROR 38000: StringIndexOutOfBoundsException was thrown while evaluating an expression. Key: DERBY-2193 URL: http://issues.apache.org/jira/browse/DERBY-2193 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.2.1.6 Reporter: Aaron Digulla During import of a file, I get this error: ERROR 38000: The exception 'java.sql.SQLException: Java exception: 'java.lang.StringIndexOutOfBoundsException: String index out of range: -14'.' was thrown while evaluating an expression. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.error.StandardException.unexpectedUserException(Unknown Source) at org.apache.derby.impl.services.reflect.ReflectMethod.invoke(Unknown Source) at org.apache.derby.impl.sql.execute.CallStatementResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) ... How am I supposed to find what's wrong in a big import? :-) It should at least mention the file which I was importing, the row and the column when the error occurred. After printing the whole exceptions chain, I got these additional two: ERROR XJ001: Java exception: 'java.lang.StringIndexOutOfBoundsException: String index out of range: -14'. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.error.StandardException.plainWrapException(Unknown Source) at org.apache.derby.impl.load.LoadError.unexpectedError(Unknown Source) at org.apache.derby.impl.load.ImportAbstract.next(Unknown Source) at org.apache.derby.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.NoPutResultSetImpl.getNextRowFromRowSource(Unknown Source) at org.apache.derby.impl.store.access.heap.HeapController.load(Unknown Source) at org.apache.derby.impl.store.access.heap.Heap.load(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.loadConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.recreateAndLoadConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.createAndLoadConglomerate(Unknown Source) at org.apache.derby.impl.sql.execute.InsertResultSet.bulkInsertCore(Unknown Source) at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at org.apache.derby.impl.load.Import.performImport(Unknown Source) at org.apache.derby.impl.load.Import.importData(Unknown Source) at org.apache.derby.catalog.SystemProcedures.SYSCS_IMPORT_DATA(Unknown Source) at org.apache.derby.exe.ac07170079x010fx9622xb7bax0011a6e80.g0(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.derby.impl.services.reflect.ReflectMethod.invoke(Unknown Source) at org.apache.derby.impl.sql.execute.CallStatementResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) ... java.lang.StringIndexOutOfBoundsException: String index out of range: -14 at java.lang.String.init(String.java:202) at org.apache.derby.impl.load.ImportReadData.readNextDelimitedRow(Unknown Source) at org.apache.derby.impl.load.ImportReadData.readNextRow(Unknown Source)
[jira] Commented: (DERBY-2193) [import] ERROR 38000: StringIndexOutOfBoundsException was thrown while evaluating an expression.
[ http://issues.apache.org/jira/browse/DERBY-2193?page=comments#action_12459381 ] Aaron Digulla commented on DERBY-2193: -- After some experiments, I found the error: This happens if you have lines in your import file which end with space (the line in question had an empty field at the end with 15 spaces in it). [import] ERROR 38000: StringIndexOutOfBoundsException was thrown while evaluating an expression. Key: DERBY-2193 URL: http://issues.apache.org/jira/browse/DERBY-2193 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.2.1.6 Reporter: Aaron Digulla During import of a file, I get this error: ERROR 38000: The exception 'java.sql.SQLException: Java exception: 'java.lang.StringIndexOutOfBoundsException: String index out of range: -14'.' was thrown while evaluating an expression. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.error.StandardException.unexpectedUserException(Unknown Source) at org.apache.derby.impl.services.reflect.ReflectMethod.invoke(Unknown Source) at org.apache.derby.impl.sql.execute.CallStatementResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) ... How am I supposed to find what's wrong in a big import? :-) It should at least mention the file which I was importing, the row and the column when the error occurred. After printing the whole exceptions chain, I got these additional two: ERROR XJ001: Java exception: 'java.lang.StringIndexOutOfBoundsException: String index out of range: -14'. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.iapi.error.StandardException.plainWrapException(Unknown Source) at org.apache.derby.impl.load.LoadError.unexpectedError(Unknown Source) at org.apache.derby.impl.load.ImportAbstract.next(Unknown Source) at org.apache.derby.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.NoPutResultSetImpl.getNextRowFromRowSource(Unknown Source) at org.apache.derby.impl.store.access.heap.HeapController.load(Unknown Source) at org.apache.derby.impl.store.access.heap.Heap.load(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.loadConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.recreateAndLoadConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.createAndLoadConglomerate(Unknown Source) at org.apache.derby.impl.sql.execute.InsertResultSet.bulkInsertCore(Unknown Source) at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) at org.apache.derby.impl.load.Import.performImport(Unknown Source) at org.apache.derby.impl.load.Import.importData(Unknown Source) at org.apache.derby.catalog.SystemProcedures.SYSCS_IMPORT_DATA(Unknown Source) at org.apache.derby.exe.ac07170079x010fx9622xb7bax0011a6e80.g0(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.derby.impl.services.reflect.ReflectMethod.invoke(Unknown Source) at org.apache.derby.impl.sql.execute.CallStatementResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
