17.10 - 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
17.10
Release Date
October 2021
Content Type
Programming Reference
Publication ID
B035-2418-061K
Language
English (United States)
To send LOB data using the deferred method, a typical parcel mode CLI application should perform the following tasks:
  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.