Metadata is data that describes other data. For example, result set metadata describes a result set. This includes the number of columns in the result set, the data types of those columns, their names, precision, nullability, and so on.
Interoperable applications should always check the metadata of result set columns. The metadata for a column in a result set might differ from the metadata for the column as returned by a catalog function. For example, suppose that an updateable column is included in a result set created by joining two tables. While f90SQLColumnPrivileges might indicate that a user can update the column, the result set metadata might not if the column is on the "many" side of the join. Many data sources can update columns on the "one" side of a join, but not on the "many" side. Even data types cannot be assumed to be the same, because the data source might promote the data type while creating the result set.
Applications require metadata for most result set operations. For example, the application uses the data type of a column to determine what kind of variable to bind to that column. It uses the byte length of a character column to determine how much space it needs to display data from that column. How an application determines the metadata for a column depends on the type of the application.
Vertical applications work with predefined tables and perform predefined operations on those tables. Because the result set metadata for such applications is defined before the application is even written and is controlled by the application developer, it can be hard-coded into the application. For example, if an order ID column is defined as a 4-byte integer in the data source, the application can always bind a 4-byte integer to that column. When metadata is hard-coded in the application, a change to the tables used by the application generally implies a change to the application code. This is rarely a problem, because such changes are generally made as part of a new release of the application.
Like vertical applications, custom applications generally work with predefined tables and perform predefined operations on those tables. For example, an application might be written to transfer data among three different data sources. The data to be transferred is generally known when the application is written. Thus, custom applications also tend to have hard-coded metadata.
Generic applications, especially those that support ad-hoc queries, almost never know the metadata of the result sets they create. Therefore, they must discover the metadata at run time using subroutines f90SQLNumResultCols, f90SQLDescribeCol, and f90SQLColAttribute.
f90SQLDescribeCol and f90SQLColAttribute are used to retrieve result set metadata. The difference between these two subroutines is that f90SQLDescribeCol always returns the same five pieces of information (a column’s name, data type, precision, scale, and nullability), while f90SQLColAttribute returns a single piece of information requested by the application. However, f90SQLColAttribute can return a much richer selection of metadata, including a column’s case sensitivity, display size, updateability, and searchability.
Many applications, especially ones that only display data, only require the metadata returned by f90SQLDescribeCol. For these applications, it is faster to use f90SQLDescribeCol than f90SQLColAttribute because the information is returned in a single call. Other applications, especially ones that update data, require the additional metadata returned by f90SQLColAttribute, and so use both subroutines. In addition, f90SQLColAttribute supports driver-specific metadata.