版次注意事項


|36.5 Chapter 3. Using Advanced Features

|36.5.1 Writing Multi-Threaded Applications

|The following should be added to the end of the "Multi-Threaded Mixed Applications" |section:

|Note:
It is recommended that you do not use the default stack size, |but instead increase the stack size to at least 256 000. DB2 requires a minimum |stack size of 256 000 when calling a DB2 function. You must ensure therefore, |that you allocate a total stack size that is large enough for both your application |and the minimum requirements for a DB2 function call. |

|36.5.2 Scrollable Cursors

|The following information should be added to the "Scrollable Cursors" section:

|36.5.2.1 Server-side Scrollable Cursor Support for OS/390

| | | | | | | |

|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.

|Cursor Attributes
| | | | | |

|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

a Forward-only is the default behavior for a scrollable cursor without the FOR UPDATE clause. Specifying FOR UPDATE on a forward-only cursor creates an updatable, lock concurrency, non-scrollable cursor.


|Supported Fetch Orientations
|

|All ODBC fetch orientations are supported via the SQLFetchScroll |or SQLExtendedFetch interfaces.

|Updating the Keyset-Driven Cursor
| | |

|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: |

|Troubleshooting for Applications Created Before Scrollable Cursor Support
|

|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:


|

|Table 24. Configuration keyword values restoring application behavior before scrollable cursor support
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.

|36.5.3 Using Compound SQL

| |

|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.

|36.5.4 Using Stored Procedures

|36.5.4.1 Writing a Stored Procedure in CLI

|

|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.

|36.5.4.2 CLI Stored Procedures and Autobinding

|

|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: |

|UNIX
|db2 bind <BNDPATH>/@db2cli.lst blocking all

|Windows and OS/2
|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.


[ 頁面頂端 | 前一頁 | 下一頁 | 目錄 | 索引 ]