Unfortunately we are not in a position to do so - we do not have any
control over what we have to call. We are historically a large mainframe
shop, and the people who provide the stored procedures think this is a
normal behavior. I think in general one should return empty sets of
things, instead of null, but...
In some cases we can figure out what the stored procedure is going to
return and call it correctly, but there are still cases we can't cover. We
can go back to JDBC with this, but I would like to be able to come up with
a way to encourage the use of iBATIS at our company.
Do you think it is likely there is some sort of way I can override a class
to create a new type of call or something that can get us able to address
this? I have not looked at any source code, and was wondering if it is
worth trying.
Thanks for the response.
Dave
Clinton Begin
<[EMAIL PROTECTED] To:
ibatis-user-java@incubator.apache.org
ail.com> cc: (bcc: David
Whipple/DTCC)
Subject: Re: Output parameters
with optional result set
04/26/2005 10:15
PM
Please respond to
ibatis-user-java
Can you wrap the wacky stored proc with a more predictable one that
returns an empty result set every time, so as to avoid the exception?
cheers,
Clinton
On 4/26/05, David Whipple <[EMAIL PROTECTED]> wrote:
> We have a situation that might address a situation that is not handled by
> iBATIS, but I wanted to describe it here and see if there is something I
> missed.
>
> The situation we have is that there is a (legacy - DB2) stored procedure
> which has input parameters and output parameters and optionally a result
> set. The application will not be able to determine if the result set is
> going to be returned or not before the call.
>
> We have the procedure defined with a parameter class, parameter map and a
> result map.
>
> If the call to the stored procedure returns a result set, we get the
result
> set and the output parameters just fine.
>
> If the call does not return a result set, an exception is thrown, and we
do
> not get the output parameters. It seems like the exception interupts it
> and prevents the processing of the output parameters.
>
> Maybe we have not set this up correctly. Can anyone suggest a way to
> handle this type of situation?
>
> Thanks,
> Dave
>
>
