Processing query (SELECT, VALUES) statements

While processing query statements, the application must also run diagnostic checks.

To process query statements in an ODBC application:

1. Analyze the executed or prepared statement and describe the structure of the result set, including the number, types, and lengths of the columns.
   If the SQL statement was generated by the application, then this step might not be necessary because the application might know the structure of the result set and the data types of each column.

   If you know the structure of the entire result set, especially if the result set contains a very large number of columns, you might want to supply Db2 ODBC with the descriptor information. This can reduce network traffic because Db2 ODBC does not have to retrieve the information from the server.

   If the SQL statement was generated at run time (for example, entered by a user), then the application has to query the number of columns, the type of each column, and perhaps the names of each column in the result set. This information can be obtained by calling SQLNumResultCols() and SQLDescribeCol(), or by calling SQLColAttribute(), after preparing or after executing the statement.

2. Optional: To bind application variables to columns in order to receive the data, retrieve column data directly into an application variable on the next call to SQLFetch().
   For each column to be retrieved, the application calls SQLBindCol() to bind an application variable to a column in the result set. The application can use the information obtained from Step 1 to determine the C data type of the application variable and to allocate the maximum storage the column value could occupy. Similar to variables bound to parameter markers using SQLBindParameter(), columns are bound to deferred arguments. This time the variables are deferred output arguments, as data is written to these storage locations when SQLFetch() is called.

   If the application does not bind any columns, as in the case when it needs to retrieve columns of long data in pieces, it can use SQLGetData(). Both the SQLBindCol() and SQLGetData() techniques can be combined if some columns are bound and some are unbound. The application must not deallocate or discard variables used for deferred output fields between the time it binds them to columns of the result set and the time Db2 ODBC writes the data to these fields.

3. Call SQLFetch() to fetch the first or next row of the result set.
   If any columns are bound, the application variable is updated. You can also write an application that fetches multiple rows of the result set into an array.

   If data conversion was indicated by the data types specified on the call to SQLBindCol(), the conversion occurs when SQLFetch() is called.

4. Optional: Call SQLGetData() to retrieve columns that were not previously bound.

   Data conversion can also be indicated here, as in SQLBindCol(), by specifying the target C data type of the application variable.

   To unbind a particular column of the result set, use SQLBindCol() with a null pointer for the application variable argument (rgbValue). To unbind all of the columns at one time, call SQLFreeHandle() on the statement handle.