Fetches the next set of rows from the file

int sm_tm_command ("CONTINUE_DOWN [ tableViewName [ tableViewScope ] ]");

tableViewName

The name of a table view in the current transaction. This parameter is case sensitive.

If tableViewName is specified, the command is applied according to the tableViewScope parameter. Since the entire table view tree might not be included, this is known as a partial command, and sm_tm_command sets TM_FULL to 0.

If tableViewName is not specified, the command is applied for each table/server view, starting with the root table view. This is known as a full command, and sm_tm_command sets TM_FULL to 1.

tableViewScope

One of the following parameters, which must be preceded by a table view name. TV_AND_BELOW which applies the command to the specified table view and all table views below it on the tree. If no parameter is specified, the transaction manager acts as though TV_AND_BELOW was supplied. BELOW_TV which applies the command to the table views below the specified table view. TV_ONLY which applies the command to the specified table view only. SV_ONLY which applies the command only to the table views of the specified server view.

CONTINUE_DOWN (not available in Web applications or three-tier processing) fetches the next set of rows from the file. Note that even though the commands CONTINUE_DOWN and CONTINUE both display the next set of data, CONTINUE_DOWN generates different a request than CONTINUE.

The availability of CONTINUE_DOWN is dependent on the setting of the fetch_directions property for the server view or screen. If the fetch_directions property is set to PV_CONT_ALWAYS (Up/Down-all modes), this command is available in update or view mode. If the fetch_directions property is set to PV_CONT_VIEW_ONLY (Up/Down-view mode), this command is available only in view mode. Otherwise, an error is generated. For more information on setting the Fetch Directions property, refer to "Scrolling Through the Select Set" in Application Development Guide.

If your screen has multiple table views, the transaction manager issues a DBMS CONTINUE_DOWN for the specified table view and any table views linked to it via server links. This displays the next set of rows for that server view. Then SELECT or VIEW processing is done for any additional child table views.

The data displayed with this command is from a continuation file; it is not refetched from the database. Therefore, any updates made to the data in this server view either by you, or by another user, are not displayed. In order to display those updates, you must again fetch the data from the database with a VIEW or SELECT command.

The advantage of using Panther's continuation file is that it prevents having shared locks on data. However, if the fetch_directions property is set to PV_CONT_ALWAYS (Up/Down-all modes), you are responsible for implementing the necessary locking scheme for concurrent users. For more information on using the Version Column property to implement optimistic locking, refer to "Implementing Optimistic Locking" in Application Development Guide.

If you want to use the database engine's facilities for non-sequential scrolling, you need to add processing for the request events to the engine-specific transaction model.

Push buttons and menu selections for the CONTINUE_DOWN command can choose to set the class property to continue_button which activates the option only in view and update modes or to continue_view_button which activates the option only in view mode.

Use CONTINUE_DOWN after SELECT or VIEW which generate a database query and display the first set of query results or after any other CONTINUE command.

The following requests can be generated by the CONTINUE_DOWN command to ascertain if the changes from the previous command have been saved and, if desired, to discard those changes:

• TM_PRE_CLOSE (described under CLOSE)

• TM_CLOSE (described under CLOSE)

• TM_QUERY (described under CLOSE)

• TM_DISCARD (described under CLOSE)

• TM_POST_CLOSE (described under CLOSE)

The following requests can also be generated for any child table views:

• TM_PRE_SELECT (described under SELECT)

• TM_SELECT (described under SELECT)

• TM_POST_SELECT (described under SELECT)

• TM_PRE_VIEW (described under VIEW)

• TM_VIEW (described under VIEW)

• TM_POST_VIEW (described under VIEW)

If TM_VIEW or TM_SELECT for a parent table view returns no data, TM_CLEAR requests are generated for all subordinate table views, but not for table views at the same level of the tree. TM_CLEAR requests are described under CLEAR.