Application Server uses the default preparedStatement from
cache. Default meaning that whatever statement is currently used
initially, then as the connection to back-end closes, Application Server
put it back to cache. Once another transaction is called such as an update
to a table(s), Application Server uses the same preparedStatement having
all the same defaulted parameters, etc containing in it. It does not make
any changes to it. PreparedStatement can be created either manually or can
be generated. For instance DB2 has its own tool to generate
preparedStatement.
Below is an example where someone might be getting
"java.lang.NumberFormatException" when using generated
preparedStatement
--> cause would be that PreparedStatement@<number>] setInt (1,
5) has been called to update table and user switches to setString --
setString(1, "")"-Call for the first parameter when tried to insert values
to same or another table. But as the prepared statement seems to expect to
be driven a "setInt()"-Call, it internally tries a "setInt()"-processing
on this parameter which fails with "NumberFormatException". This is an
application development error. To proceed, call needs to be routed to the
author of preparedStatement, such as in this case..DB2.
--> When using a preparedStatement, specifically, DB2 default to
certain values, and keep those defaults until the preparedStatement is
closed. Users can create a logic in their code not to close the connection
or perhaps re-open a connection.
--> Bear in mind that tables could be dropped/created during this
transaction and preparedStatement may not be feasible to use
Other note to remember:
Users should avoid using setString to insert numeric values into the
database. The recommended method is setInt.
|