in reply to Oracle Cursors Exceeded

The function finish() does not actually get rid of the statement handle, in Oracle terms of closing a cursor. Inside of a block, a statement handle is a perl object, so it will continue to exists (and keep its cursor open) while the block its created in still exists. The undef just insures that you won't be able to access the object again.
To fix your problem, I'd try putting all the code related to the cursor in the for loop in an anonymous block (i.e. put {...} around the code). Start the line before the "my $sth_back" and end it after the undef $sth_back. You'll also need to move your initial declaration of $back_links to the top of the function, but you can still set the value in this block. This should force Perl's garbage collection to destroy the statement handles and close the cursors.
Also, placeholders may work to automagically open/close/re-open the cursors for you. If placeholders don't work try what I wrote above.
Hope this helps, Steve

Replies are listed 'Best First'.
Re: Re: Oracle Cursors Exceeded
by runrig (Abbot) on Dec 14, 2001 at 22:50 UTC
    Shuffling the code around won't help, and using undef won't destroy the cursor when you use prepare_cached, because DBI will keep a reference to the $sth even if you don't. But I would probably move the prepare_cached from inside the for loop to outside of the loop for a small efficiency gain (so you don't have to refetch the $sth on every iteration of the loop).

    Also, you don't need to call finish when you fetch all of the rows from a cursor (it should only be used when you, e.g., fetch the first n rows and then exit the loop early), and you don't need to undef the $sth. And I would be cautious in using the fetchall_* methods; if there are alot of rows it can eat up memory; and if you don't really need the entire result set all at once, you're just as well off just using fetch (maybe even combined with bind_columns).