Specifies whether to allow an application
to run the following types of SQL statements dynamically: SQL statements
that are not captured in a pureQueryXML file, and SQL statements that
are captured in a pureQueryXML file but which have not been bound
by the StaticBinder utility.
This property
applies to an application only when executionMode is STATIC.This
property can take these values:
- TRUE
- The application runs uncaptured SQL statements dynamically. It
also runs dynamically any SQL statements that are captured in a pureQueryXML
file and the statement is configured as not bound. pureQuery Runtime
determines whether an SQL statement in a pureQueryXML file is bound
from the isBindable attribute. The values for the
attribute are TRUE the statement is bound, and FALSE the
statement is not bound.
This is the default value.
You might
choose not to set allowDynamicSQL to TRUE if you
want the application to throw SQLExceptions to help you find SQL statements
that you did not yet capture or bind.
- FALSE
- pureQuery throws an exception when methods use an uncaptured or
unbound SQL statement. These are some of the methods that can cause
an exception for this reason:
- For Java™ applications:
- Connection.prepareStatement()
- Statement.addBatch()
- Statement.execute()
- Statement.executeQuery()
- Statement.executeUpdate()
- For CLI applications:
- SQLPrepare()
- SQLExecute()
- SQLExecDirect()
Note: When the
allowDynamicSQL property
is set to TRUE, SQL SET statements that set special registers or JDBC
Connection methods that have the effect of setting special registers,
are not restricted by pureQuery Runtime. The statements are always
allowed whether or not the statement is in the pureQueryXML file.
If an SQL statement
is run with optimistic locking, the statement cannot be run statically.
Consequently, pureQuery Runtime does not capture statements that are
run with optimistic locking. The statements are not affected by the
pureQuery Runtime options
allowDynamicSQL or
capturedOnly.
Optimistic locking is enabled by the following methods:
DB2Connection.prepareDB2OptimisticLockingQuery
DB2Statement.executeDB2OptimisticLockingQuery
The
following table shows the capturedOnly, executionMode and allowDynamicSQL combinations
and resulting operations:
Table 1. capturedOnly, executionMode, and allowDynamicSQL
combinations and resulting operations:| capturedOnly |
executionMode |
allowDynamicSQL |
SQL statement matched |
Result |
|---|
| TRUE |
STATIC |
TRUE |
YES |
isBindable = True, Run the SQL statement statically isBindable
= False, Run the SQL statement dynamically
|
| TRUE |
STATIC/DYNAMIC |
TRUE/FALSE |
NO |
Return an error |
| TRUE |
STATIC |
FALSE |
YES |
isBindable = True, Run the SQL statement statically isBindable
= False, Return an error
|
| TRUE |
DYNAMIC |
TRUE/FALSE |
YES |
Run the SQL statement |
| FALSE |
STATIC |
TRUE |
YES |
isBindable = True, Run the SQL statement statically. isBindable
= False, Run the SQL statement dynamically
|
| FALSE |
STATIC |
TRUE |
NO |
Run the SQL statement dynamically |
| FALSE |
STATIC |
FALSE |
YES |
isBindable = True, Run the SQL statement statically. isBindable
= False, Return an error
|
| FALSE |
STATIC |
FALSE |
NO |
Return an error |
| FALSE |
DYNAMIC |
TRUE/FALSE |
YES/NO |
Run the SQL statement |
DB2 CLI and IBM Data Server Driver usage notes
When using DB2® Call Level Interface (CLI) or
the IBM® Data Server Driver with
pureQuery Runtime, you can use the pureQuery Runtime property as a
configuration keyword.
- IBM CLI keyword syntax
- allowDynamicSQL = TRUE | FALSE
- IBM Data Server Driver configuration
syntax
- < parameter name="allowDynamicSQL" value="TRUE | FALSE"
/>
- Equivalent IBM Data Server
Provider for .NET connection string keyword
- allowDynamicSQL=TRUE|FALSE