The following information replaces the information currently available in this section.
The table below lists DB2 CLI bind files. The first 4 bind files (db2clixx where xx is sh, sn, bh, and bn) are used mainly for execution of DB2 CLI application SQL statements. The bind files db2clish.bnd and db2clisn.bnd contains 64 sections each. The bind files db2clibh.bnd and db2clibn.bnd contains 384 sections each. Each time one of these bind files gets bound against a database, the binder will generate multiple packages whose names follow the convention listed in the table below. For each isolation level and With Hold/Without Hold property, the binder will create 3 packages (3 is the default number) from each bind file. Therefore, for each isolation level and With Hold/Without Hold combination, there are (64 * 3) + (384 * 3) or 1344 sections available for execution of DB2 CLI application SQL statements. This number should meet the need of most applications.
If your application requires more sections, you can increase the number of sections by one of the following two ways:
[dbname]
CLIPKG=5
Note that if you add the CLIPKG keyword to the [COMMON] section of db2cli.ini file, it will be applied to all databases.
db2 bind @db2cli.lst grant public CLIPKG 5
| Note: |
|
Although the autobind feature of the CLI/ODBC driver will attempt to bind CLI bind files if the CLI packages do not exist in the database or their time stamps have changed, the administrator should explicitly bind the required files. This is to avoid the following two situations:
Table 1. DB2 CLI Bind Files and Package Names
| Bind File Name | Package Name | Needed by DB2 Universal Database | Needed by DRDA servers | ||
|---|---|---|---|---|---|
| db2clish.bnd | SQLLFyxx | Yes | Yes | ||
| db2clisn.bnd | SQLLCyxx | Yes | Yes | ||
| db2clibh.bnd | SQLLDyxx | Yes | Yes | ||
| db2clibn.bnd | SQLLEyxx | Yes | Yes | ||
| db2cliws.bnd | SQLL65zz | Version 2 or later | No | ||
| db2clims.bnd | SQLL75zz | No | DB2 for MVS/ESA | ||
| db2clivm.bnd | SQLL85zz | No | SQL/DS | ||
| db2cliv1.bnd | SQLLB5zz | Version 1 only | No | ||
| db2cliv2.bnd | SQLL95zz | Version 2 or later | No | ||
| db2clias.bnd | SQLLA5zz | No | DB2 Universal Database for AS/400 | ||
| |||||
The db2cli.lst file contains the names of the required bind files for DB2 CLI to connect to DB2 Version 2 or later servers. The db2cli1.lst file contains the names of the required bind files for DB2 CLI to connect to DB2 Version 1 servers.
For DRDA servers:
The following CLI/ODBC configuration keywords have been added for v6.1 but are not documented in the manual:
This keyword is used to increase the number of sections for SQL statements in CLI/ODBC applications. If it is used, the administrator should explicitly bind the required CLI bind files with CLIPKG bind option. Also, the db2cli.ini file on the server (DB2 UDB V6.1 or later on UNIX or Intel platforms) must be updated with the same value of CLIPKG.
The QUERYTIMEOUTINTERVAL configuration keyword is used to indicate how long the CLI driver should wait between checks to see if the query has completed.
For instance, suppose SQL_ATTR_QUERY_TIMEOUT is set to 25 seconds (timeout after waiting for 25 seconds), and QUERYTIMEOUTINTERVAL is set to 10 seconds (check the query every 10 seconds). The query will not time out until 30 seconds (the first check AFTER the 25 second limit).
There may be cases where the SQL_ATTR_QUERY_TIMEOUT is set to a value which is too low, and the query should NOT be timed out. If the application cannot be modified (i.e., a third party ODBC application), then the QUERYTIMEOUTINTERVAL can be set to 0, and the CLI driver will ignore the SQL_ATTR_QUERY_TIMEOUT setting.
The description of SQL_ATTR_QUERY_TIMEOUT should be replaced with the following:
This option can be set and used to terminate long running queries. If set to 0, there is no time-out.
See 6.2.2 , QUERYTIMEOUTINTERVAL for complete details.
The following section is added to "Chapter 3. Using Advanced Features":
In addition to the distinct types, user defined structured types can also be defined
and used as the type for a table or view. Tables or views that are defined
using a structured type are called typed tables or typed views. Structured types
can be defined in a hierarchy with subtypes and supertypes. These structured types
are created using the CREATE TYPE statement. Rows of a typed table or view
are identified with an object identifier (OID) that is a reference type.
A reference type is defined to have a target type, which must be a structured type.
When the root structured type (the structured type without a supertype) is defined,
the representation type for the reference type is defined as based on a built-in
data type. Similar to user defined types (UDTs), a reference type shares its internal
representation with an existing type, but is considered to be a separate
and incompatible type for most operations.
Reference types provide a means of referring to rows in typed tables or typed views.
Applications continue to work with C data types for application variables,
and only need to consider the reference types when constructing C statements.
This means:
o All SQL to C data type conversion rules that apply to the reference type's
underlying SQL built-in type apply to the reference type.
o The reference type will have the same default C Type as the underlying
SQL built-in type.
o SQLDescribeCol() will return the representation (built-in) type information.
The target type name can be obtained by calling SQLColAttribute()
with the input descriptor type set to SQL_DESC_REFERENCE_TYPE.
o SQL predicates that involve parameter markers must be explicitly cast
to the reference type. This is required, because the application can only deal
with the built-in types. Before any operation can be performed using
the parameter, it must be cast from the C built-in type to the reference type;
otherwise, an error will occur when the statement is prepared.
For complete rules and a description of reference types, refer to the SQL Reference.
When using db2rbind to rebind all database packages for a Version 5 database migrated to Version 6, some packages (starting with SQLL) may fail. The failing packages were part of any Version 5 CAE prior to FixPak 7 These errors can safely be ignored.
However, it is necessary to upgrade all Version 5 CAEs to FixPak 7 or higher in order for the CLI/ODBC schema functions, such as SQLTables() and SQLColumns(), to be supported against a Version 6 database. Otherwise, SQL0805N errors will be returned whenever these functions are executed.
Once all CAEs have been upgraded, a Version 5 database may still contain older packages that will give errors on rebind at migration time.