469,329 Members | 1,460 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,329 developers. It's quick & easy.

About Multiple Cursor from Stored Procedure

Hi All
I am writing Import\Export routine in DB2 using stored procedure and
front end as JAVA.

For this I have two option
1) Writing five different stored procedure returning one cursor
(recordset each)
2) Writing one stored procedure returning five different cursor (five
different recordset).

So my question here is which is best option in this scenario and why?

Apr 5 '06 #1
3 5583
i think your first idea seems good.
coz when many application access the procedure
there may be performance overhead

Apr 5 '06 #2
No My Import\Export routine will be accessed once daily in off peak
hours. But application will be accessed by many other users
concurrently.
then which is best.

Apr 6 '06 #3
Suresh wrote:
No My Import\Export routine will be accessed once daily in off peak
hours. But application will be accessed by many other users
concurrently.
then which is best.


It depends... you should implement both and see what works best for you.
I'd say that if always all 5 cursors are needed and accessed, it shouldn't
matter which way you go. If not all cursors are required, splitting them
into separate procedures could be better. But then, DB2 doesn't do
anything until you actually fetch from a cursor.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Apr 6 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Matthew Houseman | last post: by
3 posts views Thread by DarthMacgyver | last post: by
8 posts views Thread by Yusuf INCEKARA | last post: by
8 posts views Thread by Suresh | last post: by
2 posts views Thread by kizmar | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by haryvincent176 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.