CLI Unicode functions accept pointers to character strings or to SQLPOINTER in their arguments. The argument strings are in UCS2 format. These functions are implemented as functions with a W suffix.
In Unicode functions that return or take strings, length arguments are passed as count of characters. For functions that return length information for server data, the display size and precision are described in number of characters. When a length can refer to string or to non-string data, the length is described in octet lengths. The function prototypes for the Unicode functions can be found in sqlcli1.h.
The following is a list of Unicode functions:
SQLColAttributeW
SQLColAttributesW
SQLColumnPrivilegesW
SQLColumnsW
SQLConnectW
SQLDataSourcesW
SQLDescribeColW
SQLDriverConnectW
SQLBrowseConnectW
SQLErrorW
SQLExecDirectW
SQLForeignKeysW
SQLGetCursorNameW
SQLGetInfoW
SQLNativeSqlW
SQLPrepareW
SQLPrimaryKeysW
SQLProcedureColumnsW
SQLProceduresW
SQLSetCursorNameW
SQLSpecialColumnsW
SQLStatisticsW
SQLTablePrivilegesW
SQLTablesW
SQLGetDiagFieldW
SQLGetDiagRecW
SQLSetConnectAttrW
SQLSetStmtAttrW
SQLGetDescFieldW
SQLSetDescFieldW
An application can be written so that it can be compiled as either a Unicode application or an ANSI application. The application is compiled as a Unicode application by turning on the UNICODE define. In this case, character data types can be declared SQL_C_TCHAR. This is a macro found in sqlcli1.h. The macro inserts SQL_C_WCHAR if the application is compiled as a Unicode application, or SQL_C_CHAR if it is compiled as an ANSI application. The function prototypes for the Unicode functions can be found in sqlcli1.h. Function calls without the W suffix will be mapped to the corresponding function with the W suffix if the application is compiled with the UNICODE define turned on.
Unicode and Ansi function calls cannot be mixed.
All SQL data types that can be converted to SQL_C_CHAR can also be converted to SQL_C_WCHAR; the converse is also true.
The following restrictions apply:
The Run-Time Client cannot be used to bind the database utilities (import, export, reorg, the command line processor) and DB2 CLI bind files to each database before they can be used with that database. You must use the DB2 Administration Client or the DB2 Application Development Client instead.
You must bind these database utilities and DB2 CLI bind files to each database before they can be used with that database. In a network environment, if you are using multiple clients that run on different operating systems, or are at different versions or service levels of DB2, you must bind the utilities once for each operating system and DB2-version combination.
The following note is missing from the book:
Any SQL statement that can be prepared dynamically, other than a query, can be executed as a statement inside a compound statement. Note: Inside Atomic Compound SQL, savepoint, release savepoint, and rollback to savepoint SQL statements are also disallowed. Conversely, Atomic Compound SQL is disallowed in savepoint.
Following is an undocumented limitation on CLI stored procedures:
If you are making calls to multiple CLI stored procedures, the application must close the open cursors from one stored procedure before calling the next stored procedure. More specifically, the first set of open cursors must be closed before the next stored procedure tries to open a cursor.
The sections within this appendix have been updated. See the "Traces" chapter in the Troubleshooting Guide for the most up-to-date information on this trace facility.
For more information on using static SQL in CLI applications, see the Web page at: http://www.ibm.com/software/data/db2/udb/staticcli/
JDBC/ODBC/CLI static profiling currently targets straightforward applications. It is not meant for complex applications with many functional components and complex program logic during execution.
An SQL statement must have successfully executed for it to be captured in a profiling session. In a statement matching session, unmatched dynamic statements will continue to execute as dynamic JDBC/ODBC/CLI calls.
An SQL statement must be identical character-by-character to the one that was captured and bound to be a valid candidate for statement matching. Spaces are significant: for example, "COL = 1" is considered different than "COL=1". Use parameter markers in place of literals to improve match hits.
When executing an application with pre-bound static SQL statements, dynamic registers that control the dynamic statement behavior will have no effect on the statements that are converted to static.
If an application issues DDL statements for objects that are referenced in subsequent DML statements, you will find all of these statements in the capture file. The JDBC/ODBC/CLI Static Profiling Bind Tool will attempt to bind them. The bind attempt will be successful with DBMSs that support the VALIDATE(RUN) bind option, but it fail with ones that do not. In this case, the application should not use Static Profiling.
The Database Administrator may edit the capture file to add, change, or remove SQL statements, based on application-specific requirements.
The last parameter - IndicatorValue - in the SQLBindFileToParam() CLI function is currently documented as "output (deferred)". It should be "input (deferred)".
The following supercedes existing information in the book.
SQL_TYPE_BASE 0 (this is not a USER_DEFINED_TYPE)
SQL_TYPE_DISTINCT 1
SQL_TYPE_STRUCTURED 2
This value can be queried with either SQLColAttribute
or SQLGetDescField (IRD only).
The following attributes are added to obtain the actual type names:
SQL_DESC_REFERENCE_TYPE
SQL_DESC_STRUCTURED_TYPE
SQL_DESC_USER_TYPE
The above values can be queried using SQLColAttribute
or SQLGetDescField (IRD only).
sqlrc = SQLBindParameter (hstmt, 2, SQL_PARAM_INPUT, SQL_C_CHAR, SQL_VARCHAR, 30,
0, &c2, 30, NULL);