1.0

Table Of Contents
Example
To begin capturing execution plans for the current connection:
CALL SYSCS_UTIL.SET_EXPLAIN_CONNECTION(1);
SYSCS_UTIL.SET_STATISTICS_TIMING
When statistics timing is turned on, you can track the timing of various aspects of a statement execution. When
statistics timing is turned off, all timing values are set to zero.
Statistics timing is an attribute associated with a connection that you turn on and off by using the
SYSCS_UTIL.SET_STATISTICS_TIMING system procedure. Statistics timing is turned off by default.
Turn statistics timing on only when the statistics are being collected with
SYSCS_UTIL.SET_EXPLAIN_CONNECTION. If you turn statistics timing on before enabling statistics
collection with SYSCS_UTIL.SET_EXPLAIN_CONNECTION, the procedure has no effect.
Turn statistics timing on by calling this procedure with a non-zero argument. Turn statistics timing off by calling
the procedure with a zero argument. See Capture Query Execution Plans for All Statements on page 260.
Syntax
SYSCS_UTIL.SET_STATISTICS_TIMING(IN SMALLINT ENABLE)
Example
To enable statistics timing:
CALL SYSCS_UTIL.SET_STATISTICS_TIMING(1);
JAR Installation Procedures
SQLJ.INSTALL_JAR, SQLJ.REMOVE_JAR, and SQLJ.REPLACE_JAR are a set of procedures in the SQLJ
schema that allow you to store jar les in a database.
Your jar le has two names:
A physical name (the name you gave it when you created it)
A SQLFire name (the SQLFire identier that you give it when you load it into a particular schema). The
SQLFire name, an SQL92 identifer, can be delimited and must be unique within a schema.
A single schema can store more than one jar le.
For more information on when and how to use these procedures, see Storing and Loading JAR Files in SQLFire
on page 111.
SQLJ.INSTALL_JAR
The SQLJ.INSTALL_JAR system procedure installs a JAR le in SQLFire.
To use the sqlj.install_jar procedure, the JAR le path must be available on the specic SQLFire data store to
which the client is connected. If the client connects directly to a known SQLFire server, then only that server
requires the JAR le to be available at the specied path when the procedure executes. However, if the client
connects using a locator then it may be connected to any available server in the distributed system. In this case,
the JAR le path should be available to all members of the SQLFire cluster (for example, from a leshare
location such as z:\) to ensure that the procedure can execute.
Note: If you cannot provide a common JAR location to ensure that the sqlj.install_jar executes, use the
sqlf install-jar command instead. SQLFire also provides an alternate mechanism to inject your JAR le
into the SQLFire system from the client itself. See Installing a JAR File Directly into SYS.JARS on page
114.
vFabric SQLFire User's Guide564
vFabric SQLFire Reference