Re: How can I specify more rows in the exact fetch ?

Matthieu DEGLIN wrote:

> Daniel Morgan a écrit dans le message
> <3D00D11E.E3E113E5_at_exesolutions.com>...
> >Matthieu DEGLIN wrote:
> >
> >> Hello,
> >>
> >> How can I specify more rows in the exact fetch ?
> >> ( It's the way given by the Oracle documentation to solve an ORA-01422)
> >>
> >> Thanxs.
> >>
> >> Matthieu DEGLIN
> >
> >The solution depends on a number of factors related to information you did
> >not provide and of which I will not guess.
> >
> >Consider providing the following:
> >
> >1. Platform and operating system
> >2. Database version
> >3. What application you were working in if it wasn't SQL*Plus
> >4. Where the code was located (form, trigger, procedure)
> >5. What the code is doing.
> >
> >Some of us haven't had a chance to get our crystal balls repaired this
> >millenium.
> >
> >Daniel Morgan
> >
>
> Here are the informations to help you help me solve the error :
>
> DECLARE
> *
> ERROR at line 1:
> ORA-01422: exact fetch returns more than requested number of rows
> ORA-06512: at line 77
>
> That error happens when executing a bloc of the following type via SQLPLUS
> under Oracle 8:
>
> DECLARE
>
> CURSOR My_CUR IS
> SELECT My_code, my_date, rowid
> FROM My_TABLE;
>
> R_My_Cur My_CUR%ROWTYPE;
>
> BEGIN
> OPEN My_CUR
>
> LOOP
> FETCH My_CUR INTO R_my_CUR;
> EXIT WHEN My_CUR%NOTFOUND;
>
> ...[Process my_Code and update it if necessary ]
>
> END LOOP;
> CLOSE My_CUR;
> commit;
> END;
>
> So Here is my question again:
>
> How can I specify more rows in the exact fetch ?
> ( It's the way given by the Oracle documentation to solve an ORA-01422)
>
> Thanxs.
>
> Matthieu DEGLIN

This is quite unusual. Do you have any parallel processing going on?

Does the above example cause the problem or only a version with a more complex cursor and code that you have snipped?

Have you attempted to isolate the exact line that, when executed, causes the error? I am thinking that what you snipped and the fact that your cursor definition is not the one you are really using may be hiding the actual culprit.

Daniel Morgan Received on Fri Jun 07 2002 - 11:03:32 CDT