Controls whether cursor requests are queued until the next request or performed immediately. Queuing close cursor requests saves a round trip and improves performance.
YES, NO, AUTO
YES Always queue the cursor close request, which saves a round trip, but can cause locks and other resources to be held after
the cursor is closed by the client. The cursor close is performed when the next request is sent to the database server on
the same connection. Any isolation level 1 cursor stability locks still apply to the cursor while the
CLOSE cursor-name database request is queued.
NO Close the cursor immediately.
AUTO Queue the cursor close request and save a round trip, only when doing so doesn't change how long locks or significant server resources are held. If the cursor uses isolation level 1 cursor stability locks, or could consume significant server resources that are not released until the cursor is closed, then the cursor is closed immediately. A query that requires a work table is an example of a cursor that can consume significant server resources.
When this connection parameter is set to YES or AUTO, cursors are not closed until the next database request.
Enabling this option can improve performance, if your network exhibits poor latency or your application sends many cursor open and close requests.
|Discuss this page in DocCommentXchange.
Send feedback about this page using email.
|Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1|