You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (JIRA)" <ji...@apache.org> on 2008/10/23 01:42:44 UTC
[jira] Closed: (DERBY-3919) Changing derby versions can cause
java.lang.NoSuchMethodError on DatabaseMetaData call
[ https://issues.apache.org/jira/browse/DERBY-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden closed DERBY-3919.
---------------------------------
Resolution: Fixed
Fix Version/s: 10.1.3.3
Checked in version bump to 10.1 branch. The change in question went in to the 10.2 release as part of the initial release not as part of a maintenance update so 10.2 should not need a version change.
> Changing derby versions can cause java.lang.NoSuchMethodError on DatabaseMetaData call
> ---------------------------------------------------------------------------------------
>
> Key: DERBY-3919
> URL: https://issues.apache.org/jira/browse/DERBY-3919
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Assignee: Kathey Marsden
> Fix For: 10.1.3.3
>
>
> Running the following program on 10.1 latest and then switching to 10.1.3.2 - (580531) and running it again causes the exception :
> C:/kmarsden/repro/10447] java GetSchemas
> xception in thread "main" java.lang.NoSuchMethodError: org.apache.derby.iapi.sql.execute.ResultSetFactory.getBulkTableS
> anResultSet(Lorg/apache/derby/iapi/sql/Activation;JILorg/apache/derby/iapi/services/loader/GeneratedMethod;ILorg/apache
> derby/iapi/services/loader/GeneratedMethod;ILorg/apache/derby/iapi/services/loader/GeneratedMethod;IZ[[Lorg/apache/derb
> /iapi/store/access/Qualifier;Ljava/lang/String;Ljava/lang/String;ZZIIIZIIZDDLorg/apache/derby/iapi/services/loader/Gene
> atedMethod;)Lorg/apache/derby/iapi/sql/execute/NoPutResultSet;
> at org.apache.derby.exe.ac05550069x011dx254bxcb49x000000134c780.fillResultSet(Unknown Source)
> at org.apache.derby.exe.ac05550069x011dx254bxcb49x000000134c780.execute(Unknown Source)
> at org.apache.derby.impl.sql.GenericActivationHolder.execute(GenericActivationHolder.java:326)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:377)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1123)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1335)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(EmbedPreparedStatement.java:244)
> at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getSimpleQuery(EmbedDatabaseMetaData.java:3086)
> at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getSchemas(EmbedDatabaseMetaData.java:1641)
> at GetSchemas.main(GetSchemas.java:9)
> import java.sql.*;
> public class GetSchemas {
> public static void main(String[] args) throws Exception{
> Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
> Connection conn = DriverManager.getConnection("jdbc:derby:wombat;create=true");
> DatabaseMetaData dbmd = conn.getMetaData();
> ResultSet rs = dbmd.getSchemas();
> while (rs.next()) {
> System.out.println(rs.getString(1));
> }
> }
> }
> Apparently the method signature changed but I thought the stored prepared statements recompiled whenever you changed versions so would not have such problems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Closed: (DERBY-3919) Changing derby versions can cause java.lang.NoSuchMethodError on DatabaseMetaData call
Posted by Myrna van Lunteren <m....@gmail.com>.
On Wed, Oct 22, 2008 at 4:42 PM, Kathey Marsden (JIRA) <ji...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/DERBY-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Kathey Marsden closed DERBY-3919.
> ---------------------------------
>
> Resolution: Fixed
> Fix Version/s: 10.1.3.3
>
> Checked in version bump to 10.1 branch. The change in question went in to the 10.2 release as part of the initial release not as part of a maintenance update so 10.2 should not need a version change.
>
>
I got confused by this comment - does this mean that your question
about changing the policy for bumping the last digit (from your
previous comment on this bug) only applies to 10.1 also?
That is, on 10.2 and up a version bump is not really necessary?
Myrna