| description | Describing Parameters | |
|---|---|---|
| title | Describing Parameters | Microsoft Docs | |
| ms.custom | ||
| ms.date | 01/19/2017 | |
| ms.prod | sql | |
| ms.prod_service | connectivity | |
| ms.reviewer | ||
| ms.technology | connectivity | |
| ms.topic | conceptual | |
| helpviewer_keywords |
|
|
| ms.assetid | 118d0f47-2afd-4955-bb47-38b1e2c2f38f | |
| author | David-Engel | |
| ms.author | v-daenge |
SQLBindParameter has arguments that describe the parameter: its SQL type, precision, and scale. The driver uses this information, or metadata, to convert the parameter value to the type needed by the data source. At first glance, it might seem that the driver is in a better position to know the parameter metadata than the application; after all, the driver can easily discover the metadata for a result set column. As it turns out, this is not the case. First, most data sources do not provide a way for the driver to discover parameter metadata. Second, most applications already know the metadata.
If an SQL statement is hard-coded in the application, the application writer already knows the type of each parameter. If an SQL statement is constructed by the application at run time, the application can determine the metadata as it builds the statement. For example, when the application constructs the clause
WHERE OrderID = ?
it can call SQLColumns for the OrderID column.
The only situation in which the application cannot easily determine the parameter metadata is when the user enters a parameterized statement. In this case, the application calls SQLPrepare to prepare the statement, SQLNumParams to determine the number of parameters, and SQLDescribeParam to describe each parameter. However, as was noted earlier, most data sources do not provide a way for the driver to discover parameter metadata, so SQLDescribeParam is not widely supported.