Statement Parameters
The statement just shown might be hard-coded in an order entry application to
insert a new row. However, parameter markers are not limited to vertical
applications. For any application, they ease the difficulty of constructing SQL
statements at run time by avoiding conversions to and from text. For example, the
part ID just shown is most likely stored in the application as an integer. If the
SQL statement is constructed without parameter markers, the application must
convert the part ID to text and the data source must convert it back to an
integer. By using a parameter marker, the application can send the part ID to the
driver as an integer, which usually can send it to the data source as an integer,
thereby saving two conversions. For long data values this is critical, as the
text forms of such values often exceed the allowable length of an SQL statement.
Parameters are legal only in certain places in SQL statements. For example,
they are not allowed in the select list (the list of columns to be returned by a SELECT statement), nor are they allowed as both operands of a binary operator such
as the equals sign (=), as it would be impossible to determine the parameter
type. In general, parameters are legal only in Data Manipulation Language (DML)
statements, and not in Data Definition Language (DDL) statements. For details,
see
When the SQL statement invokes a procedure, named parameters can be used.
Named parameters are identified by their name, not by their position in the SQL
statement. They can be bound by a call to SQLBindParameter, but the parameter is identified by the SQL_DESC_NAME field of the IPD
(implementation parameter descriptor), not by the ParameterNumber argument of SQLBindParameter. They can also be bound by calling SQLSetDescField or SQLSetDescRec. For more information on named parameters, see