While fetching the rows returned by a cursor-open command, any command can be executed using a separate command structure. For example, the application might issue a select or an update command based on the cursor data. In this case, the application must completely process the results on the separate command structure before fetching the next cursor row or sending a nested cursor command. The application could also open a new cursor. In this case, the new cursor must be opened and its command handle must be ready to return cursor rows before the application can perform another operation on the original cursor.
As an example, consider an application that selects rows from an example table employee that contains the following data:
emp_fname |
emp_lname |
emp_id |
mgr_id |
---|---|---|---|
Bob |
Burnett |
3349 |
4572 |
Alice |
Williams |
4572 |
5237 |
Thomas |
Cooper |
7028 |
3198 |
Samuel |
Jones |
6193 |
4572 |
Jennifer |
Uribe |
0969 |
4572 |
Joachin |
Palmer |
3198 |
4572 |
Jerry |
Howe |
5939 |
5237 |
George |
Latimer |
5237 |
NULL |
... |
... |
... |
... |
Here, emp_id is the employee ID number and mgr_id specifies the employee ID number of each employee’s manager. One of the application requirements is that for each fetched employee row, the application must issue another query to find out which employees work for the last-fetched employee.
If the application uses a Client-Library cursor to select rows from the employee table, it could send the second query by using a separate CS_COMMAND structure. If the application was not using cursors, it would have to issue the second query by using a second connection to the server, or wait until it had processed all the results from the original query to send a new command over the same connection.