The method Adaptive Server uses to create the cursor result set depends on the cursor and on the query plan for the cursor select statement. If a worktable is not required, Adaptive Server performs a fetch by positioning the cursor in the base table, using the table’s index keys. This executes similarly to a select statement, except that it returns the number of rows specified by the fetch. After the fetch, Adaptive Server positions the cursor at the next valid index key, until you fetch again or close the cursor.
All scrollable cursors and insensitive non-scrollable cursors require worktables to hold the cursor result set. Some queries also require worktables to generate the cursor result set. To verify whether a particular cursor uses a worktable, check the output of a set showplan, no exec on statement.
When a worktable is used, the rows retrieved with a cursor fetch statement may not reflect the values in the actual base table rows. For example, a cursor declared with an order by clause usually requires the creation of a worktable to order the rows for the cursor result set. Adaptive Server does not lock the rows in the base table that correspond to the rows in the worktable, which permits other clients to update these base table rows. Hence, the rows returned to the client from the cursor statement are different from the base table rows. See “Cursors and locking” for more information on how locks work with cursors.
In general, the cursor result set for both default and semi_sensitive cursors is generated as the rows are returned through a fetch of that cursor. This means that a cursor select query is processed like a normal select query. This process, known as cursor scans, provides a faster turnaround time and eliminates the need to read rows the application does not require.
Adaptive Server requires that cursor scans use a unique index of a table, particularly for isolation level 0 reads. If the table has an IDENTITY column and you need to create a nonunique index on it, use the identity in nonunique index database option to include an IDENTITY column in the table’s index keys so that all indexes created on the table are unique. This database option makes logically nonunique indexes internally unique and allows the indexes to be used to process updatable cursors for isolation level 0 reads.
You can still use cursors that reference tables without indexes, if none of those tables are updated by another process that causes the current row position to move. For example:
declare storinfo_crsr cursor for select stor_id, stor_name, payterms from stores where state = "CA"
The table stores, specified with the above cursor, does not have any indexes. Adaptive Server allows the declaration of cursors on tables without unique indexes, as long as you have not specified for update in the declare cursor statement. If an update does not change the position of the row, the cursor position does not change until the next fetch.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|
