Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user-java@ibatis.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Executing a Stored Procedure returning rows from a Temporary
    table
Date: Mon, 8 Aug 2005 20:29:26 +0530
Message-ID: <A8186A64C6307940AB43CFFA85397D4035344C@IND-MHP1ECL001.mastek.com>
Thread-Topic: Executing a Stored Procedure returning rows from a Temporary
    table
Thread-Index: AcWcKBRoQW2+67b9RS6F2QrPfkEklwAABcUQ
From: "Priyesh Mashelkar" <priyeshm@mastek.com>
To: <user-java@ibatis.apache.org>

Well, that was one of the alternatives.
But going to the database twice is going to shoot up the performance. Furth=
ermore, multiple clients may call this Stored Procedure and we would have t=
o somehow separate the outputs for the various clients.
But if the code iBATIS has is perfectly fine, we would definitely go for th=
is option.


-----Original Message-----
From: Koka [mailto:226057@gmail.com]
Sent: Monday, August 08, 2005 8:17 PM
To: user-java@ibatis.apache.org
Subject: Re: Executing a Stored Procedure returning rows from a
Temporary table


> I have a Stored Procedure which uses the input parameters passed to=20
> it and returns rows from a temporary table which it creates

I'd avoid changing iBatis code. Instead I'd go for a workaround like
executing procedure that fills the table (but does not return rows)
and next (in the same transaction of course) just run ordinary select
statement on tha table. Just one extra statement sounds to me far
better than changing iBastis code

Koka


MASTEK
"Making a valuable difference"
Mastek in NASSCOM's 'India Top 20' Software Service Exporters List.
In the US, we're called MAJESCO

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Opinions expressed in this e-mail are those of the individual and not that =
of Mastek Limited, unless specifically indicated to that effect. Mastek Lim=
ited does not accept any responsibility or liability for it. This e-mail an=
d attachments (if any) transmitted with it are confidential and/or privileg=
ed and solely for the use of the intended person or entity to which it is a=
ddressed. Any review, re-transmission, dissemination or other use of or tak=
ing of any action in reliance upon this information by persons or entities =
other than the intended recipient is prohibited. This e-mail and its attach=
ments have been scanned for the presence of computer viruses. It is the res=
ponsibility of the recipient to run the virus check on e-mails and attachme=
nts before opening them. If you have received this e-mail in error, kindly =
delete this e-mail from all computers.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~