This content has been marked as final. Show 8 replies
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.