The reason I say this is because in you example above you call blah.sql which the SELECT statement indicates it is the 1st level and blah calls blah2 which is the 2nd level, blah2 calls blah and you are back at the 1st level. I takes this to say that if I can have the Select_Table script as the 1st level each time I come back to this script I will be at the 1st level.

The first menu select is a script that prepares all the tables in the menu for loading this is done because the business unit wanted to be able to do just that load all the tables which means that they would be going down the menu selections loading all the tables. I have a start script that asks the user which server they want to work on and their answer sets some substitution and user variables and then calls the menu script, but when I used SET APPINFO ON and used the

SELECT SYS_CONTEXT(‘USERENV’, ‘MODULE’) FROM DUAL;

This starter script and the set variables script were in the stack thereby causing the menu script to be third in line. This series of scripts is my 1st attempt at writing SQL scripts that act as a package, I have taken the number of scripts used from around 14 to 10 but my inexperience in the use of substitution variables and combining scripts is a problem I know.

In the second sentence you said you created a wrapper script that called your script. If I understand correctly, it called your script when the user wanted to use your script so if I had a script that called say the first script which would set a substitution variable to the name of the next script to execute and then called the wrapper script which would issue the @substitution variable and with each script the wrapper calls that script set the substitution variable to the name of the next script to execute could I get around the recursion restriction issue?

Here is an example of what I am talking about:

I have a script that is named “Start” which has only two lines a DEFINE next_script statement and a call to a script named “WrapperScript” that calls “My1stScript” in “My1stScript” I do some stuff a set next_script to “My2ndScript” and call the “WrapperScript” that has @next_script.

Is this what you were talking about? If not I guess I am a bit on the slow side so could you be a bit more detailed.

Does this script call itself in the end, to get back to the menu again? sqlplus doesn’t support more than 20 levels of such recursion, thus the error.

When I had a similar situation (I wanted to rerun a script again and again) I created another, wrapper script which just had thousands of lines in it which called my script, simply something like this:

@myscript
@myscript
@myscript
@myscript
@myscript
….

That’s not ideal solution, but I don’t know any better sqlplpus-only solutions. Another option would be to use a shell script which constantly calls your script (which needs to log on again) or write something more sophisticated like a bash/ksh shell script which calls sqlplus in a separate child process and pipes any commands to that child for execution (if you are on unix)

SP2-0309: SQL*Plus command procedures may only be nested to a depth of 20.

I have a menu script that I need to keep coming back to get input from the user how do I reset the stack mechanism so this !@#$%^ error goes away and the user can execute the series of scripts till their fingers fall off?

Any assistance you can provide will be of great help. I have tryed SET APPINFO MAIN as the first line in my menu script but this did not seem to help any. I use the SET APPINFO ON immediately after issueing the SET APPINFO MAIN and used the “select SYS_CONTEXT(‘USERENV’,'MODULE’) from dual;” to see the leveling, so I am at my wits end.

just my 2 cents worth

desc v$session

..
CLIENT_IDENTIFIER VARCHAR2(64)

SQL> exec dbms_session.SET_IDENTIFIER(’01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789′);

SQL> select CLIENT_IDENTIFIER,length(CLIENT_IDENTIFIER) from gv$session where sid = (select sid from v$mystat where rownum=1);

CLIENT_IDENTIFIER LENGTH(CLIENT_IDENTIFIER)
—————————————————————- ————————-
0123456789012345678901234567890123456789012345678901234567890123 64

I found in the past using bind variables in call to dbms_application_info helped reduce the burdon on parsing at least to some extent

btw, fantastic site