Tim Dudgeon <[email protected]> writes: > Thanks for the response. > So its seems I'm probably right that my trigger is the ultimate cause. > Any ideas on how to work out what is failing here as the real culprit > seem to being masked.
Hi Tim, If you set the system property derby.stream.error.logSeverityLevel=0, so that all errors are written to derby.log, you may get some more information. Hopefully the original error is printed before the NPE is raised. > Tim > > On 29/08/2014 18:20, Rick Hillegas wrote: >> On 8/29/14 8:17 AM, Tim Dudgeon wrote: >>> Using Derby 10.10.1.1 I'm seeing strange behaviour when doing a series >>> of inserts that have triggers associated. >>> About 2000 rows get inserted fine, then it blows up completely. >>> The derby.log file contains stuff like this: >>> >>> Database Class Loader started - >>> derby.database.classpath='APP.ExtraFunctions' >>> Loaded chemaxon.misc.derby.functions.MiniregFunctions from database >>> jar "APP"."EXTRAFUNCTIONS" >>> Fri Aug 29 15:37:56 BST 2014 Thread[Default RequestProcessor,1,system] >>> (XID = 448992), (SESSIONID = 1), (DATABASE = >>> C:\Users\timbo\Documents\IJCProjects\mini-regs\Vanilla >>> Oracle/.config/derby-minireg-11-jun/db), (DRDAID = null), Cleanup >>> action starting >>> Fri Aug 29 15:37:56 BST 2014 Thread[Default RequestProcessor,1,system] >>> (XID = 448992), (SESSIONID = 1), (DATABASE = C:\Users\ ... ), (DRDAID >>> = null), Failed Statement is: INSERT INTO APP.COMPOUNDS ( ... ) VALUES >>> (?,?,?,?,?,?,?,CURRENT_TIMESTAMP,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) >>> with 31 parameters begin parameter #1: BLOB:Length=1658 :end ... >>> java.lang.NullPointerException >>> at >>> org.apache.derby.impl.sql.execute.InternalTriggerExecutionContext.cleanup(Unknown >>> Source) >>> at >>> org.apache.derby.impl.sql.execute.TriggerEventActivator.cleanup(Unknown >>> Source) >>> >>> at >>> org.apache.derby.impl.sql.execute.InsertResultSet.cleanUp(Unknown Source) >>> at >>> org.apache.derby.impl.sql.conn.GenericStatementContext.cleanupOnError(Unknown >>> Source) >>> at >>> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(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.executeLargeUpdate(Unknown >>> Source) >>> at >>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown >>> Source) >>> >>> ... >>> >>> (somethings cut out for brevity) >>> >>> >>> The trigger involved uses a custom java function that's been added to >>> the DB, so the real problem might well be there, but the stack trace >>> doesn't give much of a pointer. >>> >>> Any suggestions for where to look? >>> >>> Tim >>> >>> >>> >> Hi Tim, >> >> This looks like a weakness in GenericStatementContext.cleanupOnError(). >> The header comment for that method indicates that some more work needs >> to be done to protect the method when it trips across subsequent errors >> during statement cleanup. I have filed >> https://issues.apache.org/jira/browse/DERBY-6722 to track this defect. >> >> If I were tracking this down, I would instrument that method to make it >> print out the initial error before it calls topResultSet.cleanUp(). >> >> Thanks for bringing this weakness to our attention... >> -Rick >> -- Knut Anders
