Re: Implicit vs. Explicit cursors

Marc wrote:
>
>
> I thought one of the main reasons to replace implicit by explicit cursors
> was the fact that implicit cursors will always check for extra rows, which
> decreases performance (extra fetch needed). Especially in case of slow
> network connections, this can be a problem.
> Now you suggest that we should perform that extra check also in case of
> explicit cursors.
>
> Marc

There is something that goes on behind the scenes that seems to make implicit cursors a bad choice.

I don't have a solid example at my fingertips, but I have constructed tests in the past and have tended to find that except for extremely trivial instances the explicit cursor will always retrieve rows faster then an implicit cursor. I'm not sure why this is true.

As for the TOO_MANY_ROWS issue, this is a case where you must know your own application. If there is absolutely no risk that a second row might exist then you can exit from an explicit cursor loop after a single iteration. However, in most cases I've found that ultimately it is better to check for more then one row as part of normal data integrity checks - in other words, I WANT the application to blow up if such an error exists rather than just blithely ignoring the problem and getting caught on a data audit some day. Received on Tue May 30 2000 - 00:00:00 CDT