Repositioning, Single Buffering - Call-Level Interface Version 2

Repositioning, Single Buffering

The following information applies if an application chooses single‑buffering and a request is a single statement request. CLI will fetch the response in single buffering mode only; even if double buffering is set and reposition of response is requested.

Application

In the DBCAREA, the application:

Supplies the session id and request id of the response required.

Supplies the length of and a pointer to the response area, if the request was submitted with the Move Mode processing option.

Sets the DBCAREA fields positioning_action, positioning_value, and positioning_stmt_number, as required.

Sets the function code to FETCH(DBFFET).

Calls DBCHCL.

DBCHCL

If the specified session is active and the Teradata Database to which the session is connected supports Cursor Repositioning:

The RCB for the active request is located.

The waitdata options flag and other cursor repositioning flags are passed to MTDP with session and request identifiers.

MTDP is called to check for or wait for completion of the request.

An error is returned to the application in the following scenarios:

If keep_resp is not set to 'P' while initiating the request.

The request did not complete successfully.

The requested reposition is invalid.

Otherwise, DBCHCL places a PclROWPOSITION/PclOFFSETPOSITION parcel in the request buffer for the request, supplies the session id and request id of the specified request in the MTDPCB, sets the MTDPCB function code to MTDPCONT, and calls MTDP.

MTDP

MTDP sends a Continue Request message to the Teradata Database. It then returns control to DBCHCL.

DBCHCL

A success or error message is generated in the message field of the DBCAREA and DBCHCL returns to the application.

Application

If the return code or the error flag in the DBCAREA is not normal, the application makes the appropriate changes, and re‑submits the DBCAREA to DBCHCL, as above. Otherwise, it performs a fetch as for the non‑reposition case and consumes the unit of response. Typically, the application loops back for another unit of response until the EndRequest parcel is obtained.