JS7 JobScheduler

Space shortcuts

Page tree

Versions Compared

Old Version 5

changes.mady.by.user Andreas Püschel

Saved on

compared with

New Version 6

changes.mady.by.user Andreas Püschel

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents
outlinh1. true
outlinh1. true
1printablefalse
2stylh1. none
3indent20px

Introduction


This job template is used to execute SQL statements and SQL procedures in a database.

  • The job template makes use of JDBC connections and a the Hibernate database access layer.
  • The job template can be used to access any database for which a JDBC Driver is available with the Agent.
    • For supported DBMS products see JS7 - Database. The JS7 includes a number of JDBC Drivers for supported DBMS, see JS7 - Database.
    • For other DBMS you can provide an individual JDBC Driver and store the Driver's .jar file with the ./lib/user_lib directory of the Agent installation.
  • Delimitation
    • Consider that specific SQL language extensions such as e.g. Oracle® PL/SQL for use with anonymous functions are not supported by Hibernate.
    • For Oracle® PL/SQL use the JS7 - JITL SOSPLSQLJob
    • For Oracle® SQL*Plus use the JS7 - JITL SOSSQLPlusJob

Usage

The SOSSQLExecutor job accepts The com.sos.jitl.jobs.db.SQLExecutorJob class accepts the following arguments:


NameRequiredDefault ValuePurpose
commandyes
Carries the SQL statements.

hibernate_configuration_file

no./config/hibernate.cfg.xml

Specifies the configuration file (XML) format for Hibernate connections, see JS7 - Database. By default Agents ship without hibernate configuration files, however, if a file with the default name is available then it will be applied.

resultset_as_warning

no

Raises a warning if the SQL statement creates a result set.

exec_returns_resultset

no

If stored procedures are called that return a result set then this argument has to be set to true in order to run the stored procedure as a query.

resultset_as_variables

no

Specifies if and how a result set is forwarded to order variables for subsequent jobs:

  • false: no result set is processed .(default)
  • column_namevalue: for the first record of the result set from each column name a variable is created from that holds the column name and value.
  • name_value:  the first two columns of the result set will be added to order variables. The values of the first column of each record included with the result set will become the variable names, the values of the second column will become the variable values. 

In the above configuration the resultset_as_warning parameter is set to true to ensure that the result is written to the log file. The log file would then appear as shown in the following listing

...

languagetext
titleExample Log output with SQL query result propagated to variables
collapsetrue

...


Explanation:

  • Note that it is possible to define more than one instruction

...

  • with the command argument.
    Such instructions are then carried out in the order in which they are written and must be separated by a semicolon

...

  • .
    • Some DBMS might require and additional newline character

...

    • .
    • For example
      • update MY_TABLE set a='foo' where b='bar'
    ;&#10
      • ; commit;
  • Note also that order variables

...

  • and arguments can be

...

  • injected to the SQL statement(s) of the command argument by use of the ${variable} syntax.

Further information