This content has been marked as final. Show 8 replies
Get rid of your entire EXCEPTION section and rerun the statement.1 person found this helpful
Find out the real error and line number.
Please check the MAXOPENCURSORS parameter values. If it is too less then increase this values and try to execute. Please also check the exception for sqlerrm only. It will tell the error straight forward.
How can I check the MAXOPENCURSORS parameter? I only know the OPEN_CURSORS parameter and that is set to a sufficiently high value.
I keep reading about a precompiler setting named MAXOPENCURSORS but we don't use a precompiler, this is all straight forward PL/SQL...?
The exception in sqlerrm is defenitely "ORA-01001: invalid cursor".
What I couldn't do yet is remove the exception handler as SomeoneElse suggested because I don't want to risk passing unhandled exceptions to the invoking application, but what I did do is add a backtrace to the error-ouput:
WHEN OTHERS THEN
p_error_message := aax_zentral.get_error_message(737) || ' (' ||
to_char(l_return_code) || '/workflow:' ||
to_char(p_workflowitem) || '/scenario:' ||
to_char(rec_d_workflow.scenario) || '/id:' ||
to_char(rec_d_workflow.id) || ') ' ||
to_char(SQLCODE) || ' - ' || SQLERRM || '; Stacktrace BEGIN - ' || DBMS_UTILITY.FORMAT_ERROR_BACKTRACE;
Problem is this only returns one more line saying
ORA-06512: at "PACKAGENAME", line XY
As far as I understand, there should be at least two lines, one containing ORA-06512 and one containing the actual error, but there is only one... I'm confused.
Removing the exception handler may give you a more informative error message. You can make a copy of the subset of the package that is needed to replicate the error, then use that for your testing.
My guess would be that the invalid cursor is rec_d_workflow, and the error manifests in that block because you are referencing it there, but the actual error happens earlier in the code path.
Problem is that the error doesn't always occur. It happens sporadically and I can't do anything to reproduce it, which means I have to use the actual production setup for testing, and that of course limits my options...
About rec_d_workflow: I'm not sure whether that's technically a cursor. It's a %ROWTYPE variable that is being assigned earlier, so I would assume this can't be the cause, right?
Anyway... I will try to reproduce the error in a testing-environment where I can deactivate the exception-handler, maybe this tells me something.
has this issue been resolved. I'm facing a similar issue too. Any pointers on how to address this issue. Facing ORA-01001 on implicit cursor on SELECT INTO statement.
Nope, sorry, still working on it.
I'll let you know, if I find out anything!
i will be checking this thread for any updates.