Before the application can fetch a row of the result table
using an SQLDA structure, the application must first allocate storage
for the row.
Procedure
Code your application to do the following tasks:
- Analyze each SQLVAR description to determine how much space
is required for the value of that column.
Note that
for LOB values, when the SELECT is described, the data type given
in the SQLVAR is SQL_TYP_xLOB. This data
type corresponds to a plain LOB host variable, that is, the whole
LOB will be stored in memory at one time. This will work for small
LOBs (up to a few MB), but you cannot use this data type for large
LOBs (say 1 GB) because the stack is unable to allocate enough memory.
It will be necessary for your application to change its column definition
in the SQLVAR to be either SQL_TYP_xLOB_LOCATOR
or SQL_TYPE_xLOB_FILE. (Note that changing
the SQLTYPE field of the SQLVAR also necessitates changing the SQLLEN
field.) After changing the column definition in the SQLVAR, your application
can then allocate the correct amount of storage for the new type.
- Allocate storage for the value of that column.
- Store the address of the allocated storage in the SQLDATA
field of the SQLDA structure.
What to do next
These steps are accomplished by analyzing the description
of each column and replacing the content of each SQLDATA field with
the address of a storage area large enough to hold any values from
that column. The length attribute is determined from the SQLLEN field
of each SQLVAR entry for data items that are not of a LOB type. For
items with a type of BLOB, CLOB, or DBCLOB, the length attribute is
determined from the SQLLONGLEN field of the secondary SQLVAR entry.
In
addition, if the specified column allows nulls, the application must
replace the content of the SQLIND field with the address of an indicator
variable for the column.
DB2 10.5 for Linux, UNIX, and Windows