rc = SQLSetDescRec(hARD, 1, type, 0,
length, 0, 0, &id_no, &datalen, NULL);
Copying of descriptors
One benefit of descriptors is the fact that a single descriptor can be used for multiple purposes. For instance, an ARD on one statement handle can be used as an APD on another statement handle.
There will be other instances, however, where the application will want to make a copy of the original descriptor, then modify certain fields. In this case
SQLCopyDesc() is used to overwrite the fields of an existing descriptor with the values from another descriptor. Only fields that are defined for both the source and target descriptors are copied (with the exception of the SQL_DESC_ALLOC_TYPE field which cannot be changed).
Fields can be copied from any type of descriptor, but can only be copied to an application descriptor (APD or ARD) or an IPD. Fields cannot be copied to an IRD.
The descriptor's allocation type will not be changed by the copy procedure (again, the SQL_DESC_ALLOC_TYPE field cannot be changed).
Descriptor manipulation without using descriptor handles in CLI applications
Many CLI functions make use of descriptors, but the application itself does not need to manipulate them directly. Instead, the application can use a different function which will set or retrieve one or more fields of a descriptor as well as perform other functions.
Many CLI functions make use of descriptors, but the application itself does not need to manipulate them directly. Instead, the application can use a different function which will set or retrieve one or more fields of a descriptor as well as perform other functions. This category of CLI functions is called concise functions.
SQLBindCol()is an example of a concise function that manipulates descriptor fields.
In addition to manipulating multiple fields, concise functions are called without explicitly specifying the descriptor handle. The application does not even need to retrieve the descriptor handle to use a concise function.
The following types of concise functions exist:
v The functions SQLBindCol() and SQLBindParameter() bind a column or parameter by setting the descriptor fields that correspond to their arguments.
These functions also perform other tasks unrelated to descriptors.
If required, an application can also use the descriptor calls directly to modify individual details of a binding. In this case the descriptor handle must be retrieved, and the functions SQLSetDescField() or SQLSetDescRec() are called to modify the binding.
v The following functions always retrieve values in descriptor fields:
– SQLColAttribute() – SQLDescribeCol() – SQLDescribeParam() – SQLNumParams() – SQLNumResultCols()
v The functions SQLSetDescRec() and SQLGetDescRec() set or get the multiple descriptor fields that affect the data type and storage of column or parameter data. A single call to SQLSetDescRec() can be used to change the values used in the binding of a column or parameter.
v The functions SQLSetStmtAttr() and SQLGetStmtAttr() modify or return descriptor fields in some cases, depending on which statement attribute is specified. Refer to the "Values Stored in a Descriptor" section of the descriptors documentation for more information.
Chapter 10. Catalog functions for querying system catalog information in CLI applications
One of the first tasks an application often performs is to display a list of tables from which one or more are selected by the user. Although the application can issue its own queries against the database system catalog to get catalog
information for such a DB2 command, it is best that the application calls the CLI catalog functions instead.
One of the first tasks an application often performs is to display a list of tables from which one or more are selected by the user. Although the application can issue its own queries against the database system catalog to get catalog
information for such a DB2 command, it is best that the application calls the CLI catalog functions instead. These catalog functions, also called schema functions, provide a generic interface to issue queries and return consistent result sets across the DB2 family of servers. This allows the application to avoid server-specific and release-specific catalog queries.
The catalog functions operate by returning to the application a result set through a statement handle. Calling these functions is conceptually equivalent to using SQLExecDirect() to execute a select against the system catalog tables. After calling these functions, the application can fetch individual rows of the result set as it would process column data from an ordinary SQLFetch(). The CLI catalog functions are:
v SQLColumnPrivileges() v SQLColumns()
v SQLExtendedProcedures() v SQLExtendedProcedureColumns() v SQLForeignKeys()
v SQLGetTypeInfo() v SQLPrimaryKeys() v SQLProcedureColumns() v SQLProcedures() v SQLSpecialColumns() v SQLStatistics() v SQLTablePrivileges() v SQLTables()
The result sets returned by these functions are defined in the descriptions for each catalog function. The columns are defined in a specified order. In future releases, other columns might be added to the end of each defined result set, therefore applications should be written in a way that would not be affected by such changes.
Note: By default, Informix database servers return schema information (such as table names, and column names) in the system catalog in lowercase. This is different from DB2 data servers which return schema information in upper case.
Some of the catalog functions result in execution of fairly complex queries. It is recommended that the application save the information returned rather than making repeated calls to get the same information.