[ http://issues.apache.org/jira/browse/DERBY-680?page=comments#action_12363686 ]
Deepa Remesh commented on DERBY-680: ------------------------------------ lang/ejbql.sql tests 'abs' and 'absval' functions. So removing the prepared statements from lang/ejbql.sql does not remove any testing. Dan mentioned this in an earlier comment. The test that was giving NPE was lang/cast.sql. With the patch, I have run the test in J2ME and verified that the NPE does not occur. However, this test is still disabled in J2ME because some recent additions to the test require BigDecimal class. Because of these additional tests, it fails towards the end but the failure is not related to this issue. > In ij, executing a prepared statement with numeric/decimal parameter fails > with NullPointerException in J2ME/CDC/FP > ------------------------------------------------------------------------------------------------------------------- > > Key: DERBY-680 > URL: http://issues.apache.org/jira/browse/DERBY-680 > Project: Derby > Type: Bug > Components: Tools > Versions: 10.2.0.0 > Environment: j9_foundation VM in IBM WCTME 5.7 > Reporter: Deepa Remesh > Assignee: Deepa Remesh > Attachments: derby-680_v2.diff, derby-680_v2.status > > NPE is thrown in ij when executing prepared statement which > - has numeric/decimal parameters > - does not return any result set > Repro for this problem is the test lang/cast.sql. This test currently fails > in CDC/FP. > The following lines in the test throw NPE: > execute q10 using 'values 123456.78'; > execute q11 using 'values 123456.78'; > where q10 is "prepare q10 as 'insert into t1 (num) values cast(? as > numeric(18))';" > and q11 is "prepare q11 as 'insert into t1 (dc) values cast(? as > decimal(18))';" > The stack trace for failure is: > java.lang.NullPointerException > at org.apache.derby.impl.tools.ij.util.DisplayMulti(util.java:666) > at > org.apache.derby.impl.tools.ij.utilMain.displayResult(utilMain.java:398) > at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:290) > at org.apache.derby.impl.tools.ij.Main.go(Main.java:203) > at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:169) > at org.apache.derby.impl.tools.ij.Main.main(Main.java:75) > at org.apache.derby.tools.ij.main(ij.java:56) > This happens in the following code. Since the above prepared statements do > not return result sets, call to getMetaData() will return null. But in the > code, no check is done to see if getMetaData() returns null before calling > getColumnType. > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > // In J2ME there is no object > that represents > // a DECIMAL value. By default > use String to > // pass values around, but for > integral types > // first convert to a integral > type from the DECIMAL > // because strings like 3.4 are > not convertible to > // an integral type. > switch > (ps.getMetaData().getColumnType(c)) > { > case Types.BIGINT: > ps.setLong(c, > rs.getLong(c)); > break; > case Types.INTEGER: > case Types.SMALLINT: > case Types.TINYINT: > ps.setInt(c, > rs.getInt(c)); > break; > default: > > ps.setString(c,rs.getString(c)); > break; > } > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
