Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 29405 invoked from network); 22 Mar 2007 15:45:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 22 Mar 2007 15:45:51 -0000 Received: (qmail 29494 invoked by uid 500); 22 Mar 2007 15:45:29 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 29393 invoked by uid 500); 22 Mar 2007 15:45:29 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 29316 invoked by uid 99); 22 Mar 2007 15:45:28 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Mar 2007 08:45:28 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [67.70.253.226] (HELO smtp.thirdbrigade.com) (67.70.253.226) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Mar 2007 08:42:36 -0700 X-Ninja-PIM: Scanned by Ninja X-Ninja-AttachmentFiltering: (no action) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76C98.A9A8780B" Subject: "Syntax error" on some derby metadata calls Date: Thu, 22 Mar 2007 11:42:11 -0400 Message-ID: <0A5B5EB4DEDAF04B9D035BA5D4FC40200E4B31@3b-mail.hq.local> Thread-Topic: "Syntax error" on some derby metadata calls Thread-Index: AcdsmKhgIm0AmmX9SrSJR6W7mWRMdg== From: "Bob Durie" To: X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C76C98.A9A8780B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I've searched for this issue on jira with no luck, posting here in hopes someone has seen it or knows where it might be coming from. =20 What I'm seeing is that "sometimes" during a schema upgrade of our database, the getImportedKeys or getPrimaryKeys methods of EmbedDatabaseMetaData fail with syntax errors (see the stack trace below). If we rollback the transaction, try again, it is ALWAYS successful, but may fail later on when we do a similar operation with another table. Hence, we have a workaround (try again), but it doesn't leave me feeling very confident. =20 I do not yet have a working test case as this issue only happens when our database is in some bizarre and not easily reproducible state, but= I thought I'd toss it here to see if anyone has seen it: =20 ERROR 42X01: Syntax error: org.apache.derby.catalog.IndexDescriptor.getKeyColumnPosition. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.compile.MethodCallNode.resolveMethodCall(Unkno wn Source) at org.apache.derby.impl.sql.compile.NonStaticMethodCallNode.bindExpression (Unknown Source) at org.apache.derby.impl.sql.compile.JavaToSQLValueNode.bindExpression(Unkn own Source) at org.apache.derby.impl.sql.compile.ResultColumn.bindExpression(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumnList.bindExpressions(Unkno wn Source) at org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(Unknown Source) at org.apache.derby.impl.sql.compile.FromSubquery.bindExpressions(Unknown Source) at org.apache.derby.impl.sql.compile.FromList.bindExpressions(Unknown Source) at org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(Unknown Source) at org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(Unkno wn Source) at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(Unknown Source) at org.apache.derby.impl.sql.compile.CursorNode.bind(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.makeValid(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.rePrepare(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(Unkno wn Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown Source) at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getImportedKeys(Unknown Source) =20 One thing to note is that the process in our application calls the "connection.getMetaData" many many times, makes updates to the schema, and calls it again many times on the same transaction. While not necessarily efficient, I'm reluctant to change it as I want to know the source of the problem first. =20 Thanks, Bob ------_=_NextPart_001_01C76C98.A9A8780B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve searched for this issue on jira with no= luck, posting here in hopes someone has seen it or knows where it might be com= ing from.

 

What I’m seeing is that “sometimes̶= 1; during a schema upgrade of our database, the getImportedKeys or getPrimaryKeys= methods of EmbedDatabaseMetaData fail with syntax errors (see the stack trace below).  If we rollback the transaction, try again, it is ALWAYS successful, but may fail later on when we do a similar operation with= another table.  Hence, we have a workaround (try again), but it doesn’= ;t leave me feeling very confident.

 

I do not yet have a working test case as this issue= only happens when our database is in some bizarre and not easily reproducible= state, but I thought I’d toss it here to see if anyone has seen it:<= /o:p>

 

ERROR 42X01: Syntax error: org.apache.derby.catalog.IndexDescriptor.getKeyColumnPosition.
    at org.apache.derby.iapi.error.StandardException.newException(Unknown Sourc= e)
    at org.apache.derby.impl.sql.compile.MethodCallNode.resolveMethodCall(Unkno= wn Source)
    at org.apache.derby.impl.sql.compile.NonStaticMethodCallNode.bindExpression= (Unknown Source)
    at org.apache.derby.impl.sql.compile.JavaToSQLValueNode.bindExpression(Unkn= own Source)
    at org.apache.derby.impl.sql.compile.ResultColumn.bindExpression(Unknown= Source)
    at org.apache.derby.impl.sql.compile.ResultColumnList.bindExpressions(Unkno= wn Source)
    at org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(Unknown Sou= rce)
    at org.apache.derby.impl.sql.compile.FromSubquery.bindExpressions(Unknown= Source)
    at org.apache.derby.impl.sql.compile.FromList.bindExpressions(Unknown Sourc= e)
    at org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(Unknown Sou= rce)
    at org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(Unkno= wn Source)
    at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(Unknown Source)<= br>     at org.apache.derby.impl.sql.compile.CursorNode.bind(Unknown Source)
    at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
    at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
    at org.apache.derby.impl.sql.GenericPreparedStatement.makeValid(Unknown Sou= rce)
    at org.apache.derby.impl.sql.GenericPreparedStat= ement.rePrepare(Unknown Source)
    at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Sourc= e)
    at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Sourc= e)
    at org.apache.derby.impl.jdbc.EmbedPreparedState= ment.executeStatement(Unknown Source)
    at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown= Source)
    at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getImportedKeys(Unknown= Source)

 

One thing to note is that the process in our application calls the= “connection.getMetaData” many many times, makes updates to the schema, and calls it again many= times on the same transaction.  While not necessarily efficient, I’m reluctant to change it as I want to know the source of the problem first= .

 

Thanks,

Bob

------_=_NextPart_001_01C76C98.A9A8780B--