New issue with null values for decimal DS parameters

[hvbtup]

My fork includes the commit #1371: "Fix prepared statement setNull() #1365"

I cannot generate a report without a lot of stack trace output in the following situation.

I am using the Oracle JDBC driver.

A parent dataset selects a column IADRNR_KUNDE which is defined as NUMBER(10) in the Oracle DB. This contains an ID of an individual person. In BIRT, the datataype is shown as decimal.

A child dataset uses two input parameters: param_FIRM_ID (an ID of a company) and param_IADRNR (an ID of an individual person).

In the layout I have a structure like this: A list (bound to he parent DS) Inside the list's detail area, there are two items "Customer" and "Supplier", which both are bound to the child dataset. bound to the child dataset.

The first one uses IADRNR_KUNDE from the parent query: (I still use BIRT 4.2.1 for developing reports)

The second one uses null, because we don't want to output a person here, just the company address:

Running this report results in a BIRT error:

org.eclipse.birt.report.engine.api.EngineException: Cannot get the result set metadata.
    org.eclipse.birt.report.data.oda.jdbc.JDBCException: SQL statement does not return a ResultSet object.
SQL error #1:ORA-00932: Inkonsistente Datentypen: CHAR erwartet, NUMBER erhalten
 ;

Now I now that the valid values for IADRNR are > 0, so I tried to use 0 as a replacement for null (the SQL query is written in a way that it will treat the values null and 0 for the input parameter in the same way).

So I changed the parameter binding like this: and

With this change, the report works as expected, but there is a lot of stack trace output in the log:

Cannot get the type for parameter: 1.
org.eclipse.birt.report.data.oda.jdbc.JDBCException: Cannot get parameter type.
SQL error #1:Nicht unterstützte Funktion: checkValidIndex
 ;
    java.sql.SQLFeatureNotSupportedException: Nicht unterstützte Funktion: checkValidIndex
	at org.eclipse.birt.report.data.oda.jdbc.ParameterMetaData.getParameterType(ParameterMetaData.java:144)
	at org.eclipse.datatools.connectivity.oda.consumer.helper.OdaParameterMetaData.getParameterType(OdaParameterMetaData.java:177)
	at org.eclipse.birt.data.engine.odaconsumer.ParameterMetaData.getRuntimeParameterType(ParameterMetaData.java:217)
	at org.eclipse.birt.data.engine.odaconsumer.ParameterMetaData.<init>(ParameterMetaData.java:96)
	at org.eclipse.birt.data.engine.odaconsumer.PreparedStatement.mergeParamHintsWithMetaData(PreparedStatement.java:1501)
	at org.eclipse.birt.data.engine.odaconsumer.PreparedStatement.getParameterMetaData(PreparedStatement.java:1380)
	at org.eclipse.birt.data.engine.odaconsumer.PreparedStatement.getParameterMetaData(PreparedStatement.java:1393)
	at org.eclipse.birt.data.engine.odaconsumer.PreparedStatement.getScaleValue(PreparedStatement.java:3676)
	at org.eclipse.birt.data.engine.odaconsumer.PreparedStatement.doSetBigDecimal(PreparedStatement.java:3637)
	at org.eclipse.birt.data.engine.odaconsumer.PreparedStatement.setBigDecimal(PreparedStatement.java:3304)
	at org.eclipse.birt.data.engine.odaconsumer.PreparedStatement.setParameterValue(PreparedStatement.java:2655)
	at org.eclipse.birt.data.engine.odaconsumer.PreparedStatement.setParameterValue(PreparedStatement.java:2592)
	at org.eclipse.birt.data.engine.executor.DataSourceQuery.setInputParameterBinding(DataSourceQuery.java:1031)
...

The next thing I tried was to use java.math.BigDecimal(0) instead of a 0 literal:

This has the same effect as using 0: The report works, but a lot of log output:

Cannot get the type for parameter: 1.
org.eclipse.birt.report.data.oda.jdbc.JDBCException: Cannot get parameter type.
SQL error #1:Nicht unterstützte Funktion: checkValidIndex
 ;
    java.sql.SQLFeatureNotSupportedException: Nicht unterstützte Funktion: checkValidIndex
	at org.eclipse.birt.report.data.oda.jdbc.ParameterMetaData.getParameterType(ParameterMetaData.java:144)
	at org.eclipse.datatools.connectivity.oda.consumer.helper.OdaParameterMetaData.getParameterType(OdaParameterMetaData.java:177)
	at org.eclipse.birt.data.engine.odaconsumer.ParameterMetaData.getRuntimeParameterType(ParameterMetaData.java:217)
	at org.eclipse.birt.data.engine.odaconsumer.ParameterMetaData.<init>(ParameterMetaData.java:96)
	at org.eclipse.birt.data.engine.odaconsumer.PreparedStatement.mergeParamHintsWithMetaData(PreparedStatement.java:1501)
	at org.eclipse.birt.data.engine.odaconsumer.PreparedStatement.getParameterMetaData(PreparedStatement.java:1380)
	at org.eclipse.birt.data.engine.odaconsumer.PreparedStatement.getParameterMetaData(PreparedStatement.java:1393)
	at org.eclipse.birt.data.engine.odaconsumer.PreparedStatement.getScaleValue(PreparedStatement.java:3676)
	at org.eclipse.birt.data.engine.odaconsumer.PreparedStatement.doSetBigDecimal(PreparedStatement.java:3637)
	at org.eclipse.birt.data.engine.odaconsumer.PreparedStatement.setBigDecimal(PreparedStatement.java:3304)
	at org.eclipse.birt.data.engine.odaconsumer.PreparedStatement.setParameterValue(PreparedStatement.java:2655)
...

I think that the whole input parameter handling always was and still is broken. I mean, we explicitly specify the input parameter datatype in the DS definition (see the first screenshot), so why does ODA think it has to magically find out the parameter type in getParameterMetaData?