Client to Server Transfer - Call-Level Interface Version 2

Teradata Call-Level Interface Version 2 Reference for Workstation-Attached Systems

Product
Call-Level Interface Version 2
Release Number
15.00
Language
English (United States)
Last Update
2018-09-25
dita:id
B035-2418
lifecycle
previous
Product Category
Teradata Tools and Utilities

Client to Server Transfer

To send LOB data using the deferred method, a typical parcel mode CLI application should:

1 Set the response mode (resp_mode) to 'M' to indicate Multipart Indicator response mode. Any other setting will result in an error condition being returned.

2 Place a unique four-byte integer token in those fields that would normally contain LOB data.

3 The USING clause that references the LOB data types must specify AS DEFERRED.

4 Issue the SQL request (typically including one or more INSERTs, UPDATEs, or UPSERTs) using DBCHCL (DBFIRQ).

5 After the request completes, retrieve the response from the server using DBCHCL (DBFFET). After the request has been submitted to the server, the server will respond to the request with an ElicitData parcel. The ElicitData parcel will contain the token of the LOB that was placed in the MultipartData or MultipartIndicData parcel. The application will receive the ElicitData parcel containing the token that indicates which LOB parameter to send.

6 The application may send as much data as can be fit into the MultipartData parcel.

7 Issue DBCHCL (DBFCRQ) to send the deferred LOB data to the server with continuation_code populated appropriately.

8 Retrieve the ElicitDataReceived parcel response from the server using DBCHCL (DBFFET).

9 Repeat starting at step 7 each time an ElicitDataReceived parcel for the current LOB is received until there is no more data to send.

10 Repeat starting at step 6 each time an ElicitData parcel with a different token is received. After all the LOBs have been successfully processed, the server will respond with a Success parcel.

11 Issue DBCHCL (DBFERQ) to close the request.

The entire sequence outlined above constitutes a single, discrete request with one request number for the life of the transaction.