If errors occur during execution of SQL statements then the error messages will be stored with the "sql_error" result variable in the order of occurrence. If no errors occur then the value of the return variable is empty.
The output of the process to the stdout channel is reported from the value of this variable.
If SP2 or Oracle errors occur (SP2-*, ORA-*) then the job is terminated abnormally. The exit code is set to 98.
If the stderr channnel ist not empty then the exit code is set to 99.
The return code of the process is provided with the value of this return variable. The return code is zero if the process complets without errors.
The argument specifies the path to the SQL*Plus Client, frequently "slqplus". The SQL statements of the job are processed by the SQL*Plus Client.
The value of this argument contains common command line options available for the SQL*Plus Client. e.g. -S -L
The database connection is specified by the job with the
sys/sys_admin@localhost as sysdba
Database user accounts can be retrieved from a credential store by use of the cs://path/entry@user property.
Passwords for database accounts can be retrieved from a credential store by use of the cs://path/entry@password property.
SQL statements are specified from an input file to the SQL*Plus Client. SQL statements included in a file have to be separated by a semicolon and a subsequent new line.
Placeholders are replaced in SQL statements by the job. This is achieved by embedding a variable in the form ${argument} in the SQL statement. On execution of the job the variable "argument" is assigned the value of the argument with the same name.
An argument value can include line breaks.
This argument can be specified to embed additional SQL statements from files. The SQL*Plus script is prepended the specified files. A number of files can be specified separated by a semicolon.
The argument specifies a command to be prepended the SQL script file specified
by the
The argument specifies the timeout in seconds for the command to be executed by the SQL*Plus Client. The default is unlimitted.
The process output is parsed using this regular expression. Any matches are available as order variables.
The 'prompt' in SQL*Plus writes the output. Example:
WHENEVER SQLERROR EXIT SQL.SQLCODE
WHENEVER OSERROR EXIT FAILURE
prompt ready;
prompt foo = bar;
prompt SET hello IS world;
exit;
The 'dbms_output.put_line()' function in PL/SQL writes the output. Example:
begin
dbms_output.put_line('ready');
dbms_output.put_line('Set hello IS world');
dbms_output.put_line('foo = bar');
end;
Some remarks on regular expressions used in JobScheduler and YADE.
A regular expression is not a wildcard. To get an idea of the differences users can check the meaning of the wildcard *.txt, which will select all file names with the file name extension ".txt". A regular expression works in a similar way, the "wildcard" just looks like "^.*\.txt$". This looks a little bit strange but it is more flexible and powerfull for filtering file names than the concept of wildcards, if users want to filter more complex names or patterns.
The general syntax of a regular expression, also referred to as regex or regexp, is described here. It is different to other regular expression implementations, for example in Perl.
For further information about regular expressions see java.util.regex.Pattern
If users want only parts of a regular expresion to be case sensitive, then they have the option to use the (?-i) and [optionally] (?i) modifiers: (?-i)G[a-b](?i).*
Users dealing with Unicode characters should check if their regular expression engine properly supports Unicode.
As an extension to regular expressions the [date:] placeholder is supported. When Using this feature it is possible to create a regular expression which depends on the date that is specified with the date format string.
The value of this argument is a list of identifiers for Oracle server error messages that should be ignored. Multipe identifiers have to be separated by a semicolon (;). The prefix "ORA-" can be omitted.
The value of this argument is alist of identifiers for Oracle SQL*Plus error messages that should be ignored. Multipe identifiers have to be separated by a semicolon (;). The prefix "SP2-" can be omitted.
The path to the KeepPass database file that contains the credentials for access to the database.
Alternatively it is possible to specify the value in the URL with the ?file= query parameter.
The path to the KeePass key file that represents the key for access to the credential store. This requires a key file to be assigned the KeePass database file. If no KeePass key file is specified, then the file name is assumed from the basename of the KeePass database file and the extension .key.
Alternatively it is possible to specify the value in the URL with ?keyfile= query parameter.
The argument is used to specify a common path that is added to all entries.
Example:
credential_store_entry_path=/sos/jobscheduler
password=cs://mydb@password
In the KeePass database the entry is found in /sos/jobscheduler/mydb@password.
Alternatively it is possible to specify the value in the URL with the ?entry_path= query parameter.
The job executes a SQL*Plus script. The job runs the SQL*Plus Client in a separate process. It keeps the job in control of the program flow.
SQL statements are stored to a separate file that is specified by the
Before the SQL*Plus Client is launched for execution of the SQL script, the following steps are applied
First, for each parameter a "DEFINE" directive is generated.
These directives are written to a temporary file.
Thereafter, the specified additional files (see
Order variables can be used in the SQL script in two ways:
First, all arguments can be used in SQL*Plus statements with their name being preceeded with an ampersand "&". The arguments are defined as SQL*Plus variables by the job. The job creates a "DEFINE" directive for each argument.
Second, the names of arguments can be used directly in the SQL script. The names are replaced by value of the respective argument.
The contents of the stdout and stderr channels are available from values of the corresponding result variables. Any subsequent jobs and instructions in a workflow can access the result variables.
To report return values the job adds result variables.
The first set of variables is static in the sense that variables are always provided, such as the
variables explained with section "return variables".
In addition, order variables can be added dynamically.
The job parses output of the process and extracts variable names and values using a regular expression.
The regular expression is defined with the
Result variables are available to jobs and instructions in subsequent nodes of a workflow. The values of resul variables can be modified by subsequent jobs and instructions.
The job detects errors reported by the SQL*Plus Client. Such errors use an identifier starting with the string "SP2-" followed by a number.
In addition, the job detects errors reported by the database server on execution of the SQL script. Such errors use an identifier starting with the string "ORA-" followed by a number.
If SP2-* or ORA-* errors occur then the job is terminated abnormally. A return code 98 is set.
In addition, the error message is reported as the value of the
It is possible to ignore errors.
The
The following variables are returned,
see the
In the above example the following result variables are returned:
If a result variable is set a number of times then the last assignment is used.