[ https://issues.apache.org/jira/browse/DERBY-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222616#comment-15222616 ]
Bryan Pendleton edited comment on DERBY-6880 at 4/2/16 1:18 AM: ---------------------------------------------------------------- Here's a snip from the change that was submitted for DERBY-6414: {code} + * The 2nd array, rla has a spot for each of the columns in the table, + * with non null value for auto generated column. But in case of Update, + * resultDescription does not include all the columns in the table. It + * only has the columns being touched by the Update statement(the rest of + * the columns in the table will retain their original values), and for + * each of those touched columns, it has a duplicate entry in + * resultDescription in order to have before and after values for the + * changed column values. Lastly, it has a row location information for + * the row being updated. This difference in array content of + * resultDescription requires us to have separate implementation of this + * method for insert and update. {code} I think this description (before and after values for the changed column values, plus the row location information for the row being updated) exactly describes the 3-column ValueRow object that I am seeing when I run the reproduction. I have the before and after values for the 'status' column as columns 1 and 2 of my 3-column row, and the third column (1,8) is the row location information. was (Author: bryanpendleton): Here's a snip from the change that was submitted for DERBY-6414: <code> + * The 2nd array, rla has a spot for each of the columns in the table, + * with non null value for auto generated column. But in case of Update, + * resultDescription does not include all the columns in the table. It + * only has the columns being touched by the Update statement(the rest of + * the columns in the table will retain their original values), and for + * each of those touched columns, it has a duplicate entry in + * resultDescription in order to have before and after values for the + * changed column values. Lastly, it has a row location information for + * the row being updated. This difference in array content of + * resultDescription requires us to have separate implementation of this + * method for insert and update. </code> I think this description (before and after values for the changed column values, plus the row location information for the row being updated) exactly describes the 3-column ValueRow object that I am seeing when I run the reproduction. I have the before and after values for the 'status' column as columns 1 and 2 of my 3-column row, and the third column (1,8) is the row location information. > Update failing with java.sql.SQLDataException > ---------------------------------------------- > > Key: DERBY-6880 > URL: https://issues.apache.org/jira/browse/DERBY-6880 > Project: Derby > Issue Type: Bug > Affects Versions: 10.12.1.1 > Reporter: Simon Zee > Attachments: repro.diff, standalone.java > > > When updating a single column in a table using executeUpdate() via Vert.x I > am receiving the following exception: > java.sql.SQLDataException: Invalid character string format for type long. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:84) > at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:233) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:424) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353) > at > org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2405) > at > org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:88) > at > org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1432) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1709) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeLargeUpdate(EmbedPreparedStatement.java:320) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:309) > at > com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeUpdate(NewProxyPreparedStatement.java:410) > at io.vertx.ext.jdbc.impl.actions.JDBCUpdate.execute(JDBCUpdate.java:50) > at io.vertx.ext.jdbc.impl.actions.JDBCUpdate.execute(JDBCUpdate.java:34) > at > io.vertx.ext.jdbc.impl.actions.AbstractJDBCAction.handle(AbstractJDBCAction.java:48) > at > io.vertx.ext.jdbc.impl.actions.AbstractJDBCAction.handle(AbstractJDBCAction.java:33) > at > io.vertx.core.impl.ContextImpl.lambda$executeBlocking$15(ContextImpl.java:296) > at > io.vertx.core.impl.OrderedExecutorFactory$OrderedExecutor.lambda$new$261(OrderedExecutorFactory.java:91) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: ERROR 22018: Invalid character string format for type long. > at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290) > at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java:285) > at org.apache.derby.iapi.types.SQLChar.getLong(SQLChar.java:447) > at > org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:534) > at > org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:272) > at > org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:473) > at > org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:352) > at > org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1340) > ... 13 more > Further details and discussion can be found here: > https://mail-archives.apache.org/mod_mbox/db-derby-user/201603.mbox/%3CCAHbUnCXkHMKE1u9R3D-z9Njp8goAV7%2B0vPOmgafH8DCqG8mSpQ%40mail.gmail.com%3E > Notably, I have tried executing the same update via other means (for example, > manually via SquirrelSQL, and via the ORMLite framework) and the update > succeeds. This may be due to the exact JDBC APIs they are using (for example, > SquirrelSQL is not using a prepared statement, and ORMLite updates all the > columns when it updates a table rather than just some of them). > I have created a complete but minimal example that illustrates the problem in > the following GitHub project: > https://github.com/ssadedin/DerbyDebug > My derby / system information is as follows: > $ java -cp 'lib/*' org.apache.derby.tools.sysinfo > ------------------ Java Information ------------------ > Java Version: 1.8.0_72 > Java Vendor: Oracle Corporation > Java home: > /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre > Java classpath: lib/derby.jar:lib/derbyclient.jar > OS name: Mac OS X > OS architecture: x86_64 > OS version: 10.11.1 > Java user name: simon > Java user home: /Users/simon > Java user dir: /Users/simon/Documents/workspace/BrokenDerby > java.specification.name: Java Platform API Specification > java.specification.version: 1.8 > java.runtime.version: 1.8.0_72-b15 > --------- Derby Information -------- > [/Users/simon/Documents/workspace/BrokenDerby/lib/derby.jar] 10.12.1.1 - > (Unversioned directory) > [/Users/simon/Documents/workspace/BrokenDerby/lib/derbyclient.jar] 10.12.1.1 > - (Unversioned directory) > ------------------------------------------------------ > ----------------- Locale Information ----------------- > ------------------------------------------------------ > ------------------------------------------------------ -- This message was sent by Atlassian JIRA (v6.3.4#6332)