The following are known issues for the Database Binding Component:
The ojdbc5.jar driver for Oracle does not support prepared statements. The following error message is given:
java.sql.SQLException: Unsupported feature
No resultset is populated, and java.lang.string is selected for every parameter, regardless of the datatype.
To work around this issue, use DataDirect drivers instead of ojdbc5.jar.
No error message displayed if too many parameters are supplied in an insert prepared statement. For example, insert into table values(?,?,?,?,?) into a 3-column table causes a runtime exception, and no parameters are added.
When a prepared statement is used to update or delete parameters, the result displays the default java.lang.String datatype irrespective of the actual datatype. This is because the DataDirect connect of JDBC driver for Oracle does not support returning parameter metadata information for an update statement with mixed literal and parameterized arguments.
To work around this issue, manually change the datatype of the parameter in the generated XSD.
Built-in functions require an alias to avoid misinterpreting names of elements with special characters. For example, the prepared statement select avg(float) from table where number in(...); yields the following error:
ERROR: s4s-att-invalid-value: Invalid attribute value for 'name' in element 'element'. Recorded reason: cvc-datatype-valid.1.2.1: 'AVG(NUMBER)' is not a valid value for 'NCName'.
To work around this issue, use an alias for the function. For example: select avg(float) avg from table where number in(...);
DataDirect driver does not return correct metadata, resulting in an incorrect resultset for output parameters of stored procedures. This is a driver error, and work ticket W809210001 has been filed with DataDirect about the metadata call getProcedureColumns() returning incorrect parameters.
A datetime value cannot be inserted for SQL Server 2005 using the sqljdbc.jar driver. This was caused by a syntax error involving spaces and parentheses.
See the resolution at http://forums.microsoft.com/technet/ShowPost.aspx?siteid=17&postid=4061403.
Stored procedures do not support the BLOB (binary large object) datatype. Although the procedure runs without generating an error, a select statement fails to yield any BLOB data.
When using a Derby database for polling in a clustered environment with the Number of Records option set to a low value, the following exception is thrown and the connection pool becomes unusable:
java.sql.SQLException: Connection closed.
To work around this issue, configure the number of records per poll to a high number; for example, 100 per 1000 records. A second workaround is to create all cluster-related tables in the same database
When the Database BC is implemented in a clustered environment across multiple servers, failover does not always work because the message status in the polling table prevents the in-process messages from being picked up by another instance (or by the same instance when it resumes).
To work around this issue, manually delete records in the polling table that are have a status of “In progress” or “SENT”. This allows running instances to pick up the messages and reprocess them.
When the Database BC is used with a business process that has persistence enabled, the stored procedure fails and an exception is thrown.
When you create a Database BC WSDL document using the wizard, an XSD file named table_name.xsd is also created. If there is already an existing XSD file by that name, it is overwritten.
To work around this issue, make sure the table name is different from any existing XSD file names.