|The following should be added to the end of the "Multi-Threaded Mixed Applications" |section:
|The following information should be added to the "Scrollable Cursors" section:
|The UDB client for the Unix, Windows, and OS/2 platforms supports updatable |server-side scrollable cursors when run against OS/390 Version 7 databases. |To access an OS/390 scrollable cursor on a three-tier environment, the |client and the gateway must be running DB2 UDB Version 7.1, FixPak 3 or later.
|There are two application enablement interfaces that can access scrollable |cursors: ODBC and JDBC. The JDBC interface can only access static |scrollable cursors, while the ODBC interface can access static and keyset-driven |server-side scrollable cursors.
|The table below lists the default attributes for OS/390 Version 7 cursors |in ODBC.
|
|Table 23. Default attributes for OS/390 cursors in ODBC
Cursor Type | Cursor Sensitivity | Cursor Updatable | Cursor Concurrency | Cursor Scrollable |
---|---|---|---|---|
forward-onlya | unspecified | non-updatable | read-only concurrency | non-scrollable |
static | insensitive | non-updatable | read-only concurrency | scrollable |
keyset-driven | sensitive | updatable | values concurrency | scrollable |
|
|All ODBC fetch orientations are supported via the SQLFetchScroll |or SQLExtendedFetch interfaces.
|A keyset-driven cursor is an updatable cursor. The CLI driver appends |the FOR UPDATE clause to the query, except when the query is issued |as a SELECT ... FOR READ ONLY query, or if the FOR |UPDATE clause already exists. The keyset-driven cursor implemented |in DB2 for OS/390 is a values concurrency cursor. A values concurrency cursor |results in optimistic locking, where locks are not held until an update or |delete is attempted. When an update or delete is attempted, the database |server compares the previous values the application retrieved to the current |values in the underlying table. If the values match, then the update or delete |succeeds. If the values do not match, then the operation fails. If failure |occurs, the application should query the values again and re-issue the update |or delete if it is still applicable.
|An application can update a keyset-driven cursor in two ways: |
|Since scrollable cursor support is new, some ODBC applications that were |working with previous releases of UDB for OS/390 or UDB for Unix, Windows, |and OS/2 may encounter behavioral or performance changes. This occurs because |before scrollable cursors were supported, applications that requested a scrollable |cursor would receive a forward-only cursor. To restore an application's |previous behavior before scrollable cursor support, set the following configuration |keywords in the db2cli.ini file:
|
Configuration Keyword Setting | Description |
---|---|
PATCH2=6 | Returns a message that scrollable cursors (both keyset-driven and static) are not supported. CLI automatically downgrades any request for a scrollable cursor to a forward-only cursor. |
DisableKeysetCursor=1 | Disables both the server-side and client-side keyset-driven scrollable cursors. This can be used to force the CLI driver to give the application a static cursor when a keyset-driven cursor is requested. |
UseServerKeysetCursor=0 | Disables the server-side keyset-driven cursor for applications that are using the client-side keyset-driven cursor library to simulate a keyset-driven cursor. Only use this option when problems are encountered with the server-side keyset-driven cursor, since the client-side cursor incurs a large amount of overhead and will generally have poorer performance than a server-side cursor. |
|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 following supplements information in the book:
|The CLI/ODBC driver will normally autobind the CLI packages the first time |a CLI/ODBC application executes SQL against the database, provided the user |has the appropriate privilege or authorization. Autobinding of the CLI packages |cannot be performed from within a stored procedure, and therefore will not |take place if the very first thing an application does is call a CLI stored |procedure. Before running a CLI application that calls a CLI stored procedure |against a new DB2 database, you must bind the CLI packages once with this |command: |
|db2 bind <BNDPATH>/@db2cli.lst blocking all
|db2bind "%DB2PATH%\bnd\@db2cli.lst" blocking
||The recommended approach is to always bind these packages at the time |the database is created to avoid autobind at runtime. Autobind can fail |if the user does not have privilege, or if another application tries to autobind |at the same time.