iBATIS is calling different JDBC APIs for the different statements. When
you have it configured as a procedure, iBATIS is calling JDBC's prepareCall
API. Otherwise, iBATIS is calling JDBC's prepareStatement API. This is why
you're seeing different results from the different configurations.
I still believe that the <procedure> problem lies in the MySQL driver. If
you're adventurous, try this raw JDBC code to see if you still get the error
(this is essentially what iBATIS is doing with the <statement>
configuration):
Connection connection = ... (get the connection from Driver manager)
CallableStatement cs = connection.prepareCall ("{CALL
deleteDatasetByResearcherIdAndId(?,?)}");
cs.setBigDecimal(1, new BigDecimal("1"));
cs.setBigDecimal(2, new BigDecimal("1"));
cs.execute();
Also look at these very recent MySQL bugs for similar issues (not related to
iBATIS):
http://bugs.mysql.com/bug.php?id=24065
http://bugs.mysql.com/bug.php?id=22297
Jeff Butler
On 11/22/06, Peter Andrews <[EMAIL PROTECTED]> wrote:
I think the null pointer exception is related to iBATIS because if I wrap
the identical call in a delete element rather than a procedure element, the
procedure is called and works just fine.
This works:
<delete id="deleteDatasetByResearcherIdAndId" parameterClass="Map">
{CALL deleteDatasetByResearcherIdAndId(#pResearcherId:NUMERIC#,
#pDatasetId:NUMERIC#)}
</delete>
This throws null pointer exception:
<procedure id="deleteDatasetByResearcherIdAndIdProcedure"
resultClass="Integer" parameterClass="Map">
{CALL deleteDatasetByResearcherIdAndId(#pResearcherId:NUMERIC#,
#pDatasetId:NUMERIC# )}
</procedure>
This hangs:
<statement id="deleteDatasetByResearcherIdAndIdStatement"
resultClass="Integer" parameterClass="Map">
{CALL deleteDatasetByResearcherIdAndId(#pResearcherId:NUMERIC#,
#pDatasetId:NUMERIC#)}
</statement>
