Return-Path: X-Original-To: apmail-db-derby-dev-archive@www.apache.org Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E19D419A31 for ; Thu, 28 Apr 2016 02:39:13 +0000 (UTC) Received: (qmail 92192 invoked by uid 500); 28 Apr 2016 02:39:13 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 92118 invoked by uid 500); 28 Apr 2016 02:39:13 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 91730 invoked by uid 99); 28 Apr 2016 02:39:13 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Apr 2016 02:39:13 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 1F81D2C1F76 for ; Thu, 28 Apr 2016 02:39:13 +0000 (UTC) Date: Thu, 28 Apr 2016 02:39:13 +0000 (UTC) From: "ASF subversion and git services (JIRA)" To: derby-dev@db.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (DERBY-6880) Update failing with java.sql.SQLDataException MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/DERBY-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15261437#comment-15261437 ] ASF subversion and git services commented on DERBY-6880: -------------------------------------------------------- Commit 1741380 from [~bryanpendleton] in branch 'code/trunk' [ https://svn.apache.org/r1741380 ] DERBY-6880: Update failing with java.sql.SQLDataException This change reverts part of the changes made by revision 1628596 for DERBY-6742. Specifically, the section of code added to UpdateResultSet.collectAffectedRows is removed. That code caused problems with certain SQL UPDATE statements which were compiled with Statement.RETURN_GENERATED_KEYS. The new test cases added by this change include several examples of such SQL statements. The JDBC documentation for the intended behavior of UPDATE statements with the RETURN_GENERATED_KEYS option is unclear; the intended behavior is much clearer with INSERT statements. Given that I don't understand the intended behavior, it seems safer to me to return Derby to the previous state for UPDATE statements; namely, that no attempt is made to compute the set of generated keys for an UPDATE statement. > 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, undo6742.diff, undoMoreTests.diff > > > 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)