Execute just has Oracle prepare the cursor it does not fetch rows. It sets
up all the stuff before it actually fetches the data. At that point the
cursor is set up but you have not fetched any data. Once you do a fetch
then it actually gets the number of rows you have requested. It does NOT
retrieve the rows into memory when you set up the cursor. It does fetch the
rows (as you ask for them) when you start fetching. Use the array
interface; it might make it go faster.
Jim
--
Replace part of the email address: kennedy-down_with_spammers_at_attbi.com
with family. Remove the negative part, keep the minus sign. You can figure
it out.
"csatk" <member21664_at_dbforums.com> wrote in message
news:2347221.1041677227_at_dbforums.com...
>
> Hi All,
> I have a strange problem using CallableStatement, Ref Cursors and
> Stored Procedures.
> I am using Oracle 9i, JDK 1.4, and Oracle Thin JDBC Driver.
> I have a Oracle Stored Procedure which returns a Ref Cursor. The stored
> procedure performs select operations over a huge dataset.
> Now the strange part.
> The call to execute, on the callable statement takes a few milliseconds
> callableStatment.execute();
> but, the call to retrieve the Cursor from the statement takes
> about a miunte.
> resultSet = ((OracleCallableStatement)callableStatment).getCursor(9);
>
> It almost seems like the retrieval of the cursor is what triggers the
> querying/population of the cursor in the database.
>
> I would really appreciate it if anyone could tell me as to what is
> happening here?
>
> Thanks
> Satish
>
> --
> Posted via http://dbforums.com
Received on Sat Jan 04 2003 - 11:01:27 CST
