DB2 CURSOR

WHAT IS CURSOR?
In order to be able to process a results table that contains more than one row,
you have to use cursors.
A cursor is a pointer that identifies the current row in a results table. A cursor
can only point to one row at a time.
● Is required for SELECT of multiple rows
● Is never used for INSERT - May be reused (CLOSED + new OPEN)
● Will be close at COMMIT unless declared with WITH HOLD
Multiple cursors:
● May be defined in a program
● May work with the same table
● May be open simultaneously
There are four steps in using a cursor:

1. Use DECLARE CURSOR to specify a cursor for result table.

2. Issue OPEN statement to begin cursor processing.
3. Issue one FETCH statement for each row in result table.
4. Conclude cursor processing by issuing CLOSE statement.
DECLARE CURSOR specifies what the results table should contain. It
contains a SELECT statement where you name the columns you want to
retrieve, the table that contains them, and the selection conditions for them.

Example: DECLARE CURSOR for retrieving instructor information for a course.

EXEC SQL

DECLARE INSTCURS CURSOR FOR

SELECT DISTINCT PERSON.FNAME,

PERSON.LNAME, OFFICE#, OFFICE_PHONE#

FROM PERSON, TEACHER, SECTION

WHERE SECTION.COURSE# = :COURSE-NUM

AND PERSON.SSN = TEACHER.SSN

AND SECTION .SSN = PERSON

END-EXEC
DECLARE CURSOR:
The SELECT statement in the DECLARE CURSOR
statement simply specifies the characteristics of the result
table that will be associated with the cursor.
Coding DISTINCT keyword in the SELECT component of a
DECLARE CURSOR statement directs DB2 to exclude
duplicate rows from the results table.
ORDER-BY statement allows you to sort the result table
OPENING A CURSOR:

OPEN statement generates the results table associated

with the cursor and positions the cursor just before the
first row of the table.
EXEC SQL
OPEN INSTCURS
END-EXEC.
RETRIEVING A ROW FROM A CURSOR-
CONTROLLED RESULTS TABLE:
Use the FETCH statement to retrieve a row from a results table that has
a cursor.
EXEC SQL
FETCH INSTCURS
INTO :FNAME, :LNAME, :OFFICE#,
:OFFICE_PHONE#
END-EXEC
Evaluate the SQLCODE after each FETCH. When SQLCODE
equals +100, you have reached the end of the result table (similar to
 CLOSING A CURSOR
CLOSE statement releases the results table associated with the
specified cursor.
EXEC SQL
CLOSE INSTCURS
END-EXEC.
Closing a table is not required, since DB2 automatically closes all tables
when the program ends. However, closing a table yourself allows you to
release a substantial amount of memory the table uses and it allows you to
reopen a table without ending the program
DELETE VIA A CURSOR
DELETE VIA A CURSOR

● This skeleton code demonstrates using a cursor to identify rows to

be DELETEd.
● The DECLARE, OPEN, FETCH, and CLOSE CURSOR logic is not
changed.
● DELETE WHERE CURRENT OF CURSOR deletes the row presently
identified by the cursor.
● This form of DELETE can be used if the data contained in a row is
needed by the application before the row is to be DELETEd. One
requirement for such logic would be to generate a report of rows
DELETEd by the application
UPDATE VIA A CURSOR
UPDATE VIA A CURSOR

● UPDATE WHERE CURRENT OF CURSOR updates the row presently identified by the cursor. It
can be used if the results set is needed by the application and some or all of the rows in the
result set need to be updated.
● The DECLARE CURSOR has an additional FOR UPDATE OF clause which identifies columns
that may be UPDATEd via the cursor. This clause will also cause DB2 to use a different row
locking strategy when rows are retrieved. This row locking strategy supports the possibility
that a row or set of rows MAY be UPDATEd via the CURSOR. The strategy, which employs U-
locks, can minimize the possibility for deadlocks on rows.
● The FOR UPDATE OF clause can also be specified for a CURSOR that is intended for DELETE
WHERE CURRENT OF CURSOR. Specifying the clause will cause DB2 to employ the U-lock
strategy which will minimize row deadlocking.
 OPTIMIZE FOR n ROWS
When an application executes a SELECT statement, DB2 assumes that the application will retrieve all the
qualifying rows. This assumption is most appropriate for batch environments. However, for interactive SQL
applications, such as SPUFI, it is common for a query to define a very large potential result set but retrieve only the
first few rows. The access path that DB2 chooses might not be optimal for those interactive applications.

The OPTIMIZE FOR n ROWS clause lets an application declare its intent to do either of these things:

● Retrieve only a subset of the result set.

● Give priority to the retrieval of the first few rows.

DB2 uses the OPTIMIZE FOR n ROWS clause to choose access paths that minimize the response time for
retrieving the first few rows.

Number of rows can be retrieved with OPTIMIZE FOR n ROWS: The OPTIMIZE FOR n ROWS clause does not
prevent you from retrieving all the qualifying rows. However, if you use OPTIMIZE FOR n ROWS, the total elapsed
time to retrieve all the qualifying rows might be significantly greater than if DB2 had optimized for the entire result
set.
EXAMPLE
Suppose that you query the employee table regularly to determine the employees with the highest salaries. You
might use a query like this:

CASE - I

CASE - II
FETCH FIRST k ROWS ONLY

FETCH FIRST n ROWS ONLY clause is used for fetching a limited number of rows. In some
applications, you execute queries that can return a large number of rows, but you need only a
small subset of those rows. Retrieving the entire result table from the query can be inefficient.
You can specify this clause in a SELECT statement to limit the number of rows in the result table
of a query to n rows.

Unlike OPTIMIZE FOR n ROWS, the database manager ceases processing the query once the
specified number of rows have been retrieved when FETCH FIRST k ROWS ONLY is specified

When the number of rows to be retrieved is small, there is no need to specify the OPTIMIZE
FOR n ROWS clause in addition to the FETCH FIRST k ROWS ONLY clause. However, if k is
large and you want to optimize by getting the first n rows quickly with a possible delay for the
subsequent rows, specify both.
EXAMPLE

Suppose that you write an application that requires information on only the 20 employees with the highest salaries. To
return only the rows of the employee table for those 20 employees, you can write a query like this: