How to use parameters in oracle SQL script????

Question

Right now I am writing a SQL script to create a schema and build the objects of this schema....
I use a .net winform program to run sqlplus to parse this sql script ...
The problem is that the schema name and the tablespace's location and the sys password must be input by the user, so my SQL script should use these runtime input parameters instead of const parameters....
So, how to use parameter in SQL script ...........
Are there some example scripts in oracle home directory for me to refer to????

Answer 1

Hi,
UNISTD wrote:
thanks .....
what's the difference between variable , define, accept in sqlplus ???VARIABLE declares (but does not assign a value to) a bind variable. Unlike substitution variables, bind variables are passed to the back end to be compiled, and they can only be values in certain data types. You can not use a bind vaiable in place of an identifier, so to do something like
CREATE USER  &1 ...a bind variable won't work.
"DEFINE x = y" sets the substitution variable &x to have the value y. There is no user interaction (unless x or y happen to contain undefined substtiution variables).
"DEFINE x" shiows the value of the substitution variable &x, or, if it is undefined, raises a SQL*Plus error. I use this feature below.
ACCEPT sets a substitution variable with user interaction.
And if the user miss some parameters in “sqlplus /nolog ssss.sql par1 par2 par5 par6”, how to use default value of the miss parameters??Don't you need a @ befiore the script name, e.g.
sqlplus /nolog @ssss.sql par1 par2 par5 par6Sorry, I don't know of any good way to use default values.
The foloowing works, but, as you can see, it's ugly.
"DEFINE 1" display a message like
DEFINE 1            = "par1" (CHAR)if &1 is defined; otherwise,it will display a SQL*Plus error message like
SP2-035: symbol 1 is UNDEFINEDNotice that the former contains an '=' sign, but the latter does not.
The best way I know to use default values is to run the DEFINE command, save the output to a filee, read the file, and see if it's an error message or not.
So you can use a script like this:
--     This is  DEFINE_DEFAULT.SQL
SPOOL     got_define_txt.sql
DEFINE     &dd_old
SPOOL     OFF
COLUMN     dd_new_col     NEW_VALUE     &dd_new
WITH     got_define_txt     AS
     SELECT  q'[
          @got_define_txt
]'               AS define_txt
     FROM    dual
SELECT     CASE
         WHEN  define_txt LIKE '%=%'
         THEN  REGEXP_REPLACE ( define_txt
                           , '.+"
([^"]*)
                     , '\1'
         ELSE  '&dd_default'
     END        AS dd_new_col
FROM     got_define_txt
{code}
and start your real script, ssss.sql, something like this:
{code}
DEFINE          dd_new     = sv1
DEFINE          dd_old     = 1
DEFINE          dd_default     = FOO
@DEFINE_DEFAULT
DEFINE          dd_new     = sv2
DEFINE          dd_old     = 2
DEFINE          dd_default     = "Testing spaces in value"
@DEFINE_DEFAULT
{code}
when this finishes running, the substitution variable &sv1 will either have the value you passed in &1 or, if you didn't pass anything, the default value you specified, that is FOO.
Likewise, &sw2 will have the value you passed, or, if you didn't pass anything, the 23-character string 'Testing spaces in value'.
Here's how it works:
Define_default.sql puts the output of the "DEFINE x" command into a column, define_txt, in a query.  That query displays either the existing value of the substitution variable indicated by &dd_old or, if it is undefined, the default value you want to use, which is stored in the substitution variable &dd_default.  The substitution variable named in &dd_new is always set to something, but that something may be its existing value.
Notice that the paramerters to define_default.sql must be passed as global varibales.
Why didn't I just use arguments, so that we could simply say:
{code}
@DEFINE_DEFAULT  sv1  1  FOO
{code}
?  Because that would set the substitution variables &1, &2 and &3, which are miost likely the very ones in which you're interested.
I repeat: there must be a better way, but I'm sorry, I don't know what it is.
I usually don't do the method above.  Instead, I always pass the required number of parameters, but I pass dummy or plce-holder values.
For example, if I wanted to call ssss.sql, but use defulat vlaues for &1 and &3, then I would say something like:
{code}
@ssss  ?  par2  ?
{code}
and, inside ssss.sql, test to see if the values are the place holder '?', and, if so, replace them with some real default value.  The use has  to remember what the special place holder-value is, but does not need to know anything more, and only ssss.sql itself needs to change if the default values change.