Dynamic SQL allows an application to define and run SQL statements at program run time. An application that provides for dynamic SQL accepts as input (or builds) an SQL statement in the form of a character string. The application does not need to know what type of SQL statement it will run.
The application:
Interactive SQL is an example of a dynamic SQL program. SQL statements are processed and run dynamically by interactive SQL.
The processing of dynamic SQL can have substantially
higher overhead than that for static SQL because the statement may need to
be fully processed at run time. In the worst case, the statement must be fully
prepared, bound, and optimized by the database before it is run. In many other
cases, if the statement has been run before, parts of the processing can be
skipped because of the algorithms used and caches maintained by the database.
These features allow DB2 for iSeries™ to
provide good performance for dynamic SQL statements. If performance for your
dynamic application is critical, consider using the extended dynamic capability
using the QSQPRCED API. This feature allows the application to maintain a
persistent cache of SQL statements and substantially reduces runtime overhead
when running the application.
The ALWBLK(*ALLREAD) CRTSQLxxx option will imply a FOR READ ONLY declaration for all cursors that do not explicitly code FOR UPDATE OF or have positioned deletes or updates that refer to the cursor. Cursors with an implied FOR READ ONLY will benefit from the second item in this list.
Some dynamic SQL statements require use of address variables. RPG/400 programs require the aid of PL/I, COBOL, C, or ILE RPG programs to manage the address variables.