db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Alan Shepherd (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3221) "java.sql.SQLException: The conglomerate (-5) requested does not exist." from Derby 10.3.1.4 embedded within Eclipse 3.3 and RAD 7.0
Date Wed, 12 Dec 2007 21:37:43 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551117
] 

James Alan Shepherd commented on DERBY-3221:
--------------------------------------------

Yes it's pretty deep in a trigger.

I think the statement that kicks everything off, that you request is

INSERT INTO SubTTT ( nShapeID , nSubShapeID , nColorID ) SELECT DISTINCT C.nRCID , S.nRCID
, (S
ELECT nColorID FROM Colorition WHERE nIsCCC = 1) FROM LegacySubCCC SC JOIN LegacyCCC C ON
SC.nRunID = ? AND C.nRunID = ? AND C.nICCCID = SC.nICCCID JOIN LegacyCCC S ON S.nRunID = ?
AND S.nICCCID = SC.nISubCCCID LEF
T JOIN SubTTT SO ON SO.nShapeID = C.nRCID AND SO.nSubShapeID = S.nRCID WHERE SO.nShapeID IS
NULL

which is logged up there somewhere.

There are no errors before what I have posted, but the execution of the above statement is
several pages back in the log.

As you say, changing the code a bit stops the bug. Interestingly, if I select out of a different
Legacy* table then I don't get the bug.

Even more interestingly, if I shove the data in a Temporary table, then select out of that,
I get the bug still! And the conglomerate number changes.

Absolutely 100% the same each time I run the whole shebang.

Not really multi-threaded, there is an ij session on stdout/in so that I can take a peek in
the embedded database while debugging. However, I don't think this  connects before the bug
bites. The java app does try to connect to an existing database, and if this fails, connect
again with ;create=true, and runs the create script. Actually, initially, there may be another
connection opened adn closed that just finds out what version of derby is running etc, but
this closes straight after having a look around.

I'm just trying to run with fewer rows in the table that gets selected from, for the hell
of it, as the bug arises with the largest row count Legacy table.
Initial results seem to show that fewer rows (we're only talking 4 being few, 100 being many)
doesn't trigger the bug. I'm gonna check that this still exercises the same code path.


> "java.sql.SQLException: The conglomerate (-5) requested does not exist." from Derby 10.3.1.4
embedded within Eclipse 3.3 and RAD 7.0
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3221
>                 URL: https://issues.apache.org/jira/browse/DERBY-3221
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.3.1.4
>         Environment: Windows Vista Ubuntu Linux on IBM's VM (RAD 7.0)
>            Reporter: Tim Halloran
>
> We are getting an SQLException when several prepared statement deletes are done upon
an existing database.  As far as we can tell this exception should never occur unless (evil)
things like deleting the database or editing files occurs.  This is using the embedded driver
within a plug-in inside RAD 7.0 (and Eclipse 3.3).
> I'm not sure what else to submit that might be helpful.
> java.sql.SQLException: The conglomerate (-5) requested does not exist.
>  at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
>  at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
>  at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
>  at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
>  at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
>  at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
>  at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
>  at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
>  at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
>  at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>  at java.lang.reflect.Method.invoke(Unknown Source)
>  at com.surelogic.sierra.jdbc.LazyPreparedStatementConnection$LazyPreparedStatement.invoke(Unknown
Source)
>  at $Proxy1.execute(Unknown Source)
>  at com.surelogic.sierra.jdbc.finding.FindingManager.delete(Unknown Source)
>  at com.surelogic.sierra.jdbc.finding.ClientFindingManager.updateLocalFindings(Unknown
Source)
>  at com.surelogic.sierra.jdbc.project.ClientProjectManager.synchronizeProject(Unknown
Source)
>  at com.surelogic.sierra.client.eclipse.jobs.SynchronizeJob.synchronize(Unknown Source)
>  at com.surelogic.sierra.client.eclipse.jobs.SynchronizeJob.run(Unknown Source)
>  at org.eclipse.core.internal.jobs.Worker.run(Unknown Source)
> Caused by: ERROR XSAI2: The conglomerate (-5) requested does not exist.
>  at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
>  at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown
Source)
>  at org.apache.derby.impl.store.access.RAMTransaction.openScan(Unknown Source)
>  at org.apache.derby.impl.sql.execute.TemporaryRowHolderResultSet.getNextRowCore(Unknown
Source)
>  at org.apache.derby.impl.sql.execute.TemporaryRowHolderResultSet.getNextRow(Unknown
Source)
>  at org.apache.derby.impl.sql.execute.IndexChanger.finish(Unknown Source)
>  at org.apache.derby.impl.sql.execute.IndexSetChanger.finish(Unknown Source)
>  at org.apache.derby.impl.sql.execute.RowChangerImpl.finish(Unknown Source)
>  at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source)
>  at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
>  ... 14 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message