As soon as a statement handle has been allocated, there are two methods
of specifying and executing SQL statements:
- Prepare, and then execute:
- Call SQLPrepare() with an SQL statement as an argument.
- Call SQLSetParam(), if the SQL statement contains parameter
markers.
- Call SQLExecute()
- Execute direct:
- Call SQLSetParam(), if the SQL statement contains parameter
markers.
- Call SQLExecDirect() with an SQL statement as an argument.
The first method splits the preparation of the statement from the processing.
This method is used when:
- The statement is processed repeatedly (typically with different parameter
values). This avoids having to prepare the same statement more than once.
- The application requires information about the columns in the result set,
before statement processing.
The second method combines the preparation step and the processing step
into one. This method is used when:
- The statement is processed once. This avoids having to call two functions
to process the statement.
- The application does not require information about the columns in the
result set, before the statement is processed.
Binding parameters in SQL statements in a DB2® UDB CLI application
Both processing methods allow the use of parameter markers in place of
an expression (or host variable in embedded SQL) in an SQL statement.
Parameter markers are represented
by the '?' character and indicate the position in the SQL statement where
the contents of application variables are to be substituted when the statement
is processed. The markers are referenced sequentially, from left to right,
starting at 1.
When an application variable is
associated with a parameter marker, it is
bound to the
parameter marker. Binding is carried out by calling the
SQLSetParam() function
with:
- The number of the parameter marker
- A pointer to the application variable
- The SQL type of the parameter
- The data type and length of the variable.
The application variable is called a
deferred argument because
only the pointer is passed when
SQLSetParam() is called.
No data is read from the variable until the statement is processed. This applies
to both buffer arguments and arguments that indicate the length of the data
in the buffer. Deferred arguments allow the application to modify the contents
of the bound parameter variables, and repeat the processing of the statement
with the new values.
When calling SQLSetParam(), it is possible
to bind a variable of a different type from that required by the SQL statement.
In this case DB2 UDB
CLI converts the contents of the bound variable to the correct type. For example,
the SQL statement might require an integer value, but your application has
a string representation of an integer. The string can be bound to the parameter,
and DB2 UDB
CLI converts the string to an integer when you process the statement.
For more information and examples refer to:
If the SQL statement uses parameter markers instead of expressions (or
host variables in embedded SQL), you must bind the application variable to
the parameter marker.