How Many DBCAREAs to Use? - Call-Level Interface Version 2

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

Deployment
VantageCloud
VantageCore
Edition
Enterprise
IntelliFlex
Lake
VMware
Product
Call-Level Interface Version 2
Release Number
20.00
Published
January 2024
ft:locale
en-US
ft:lastEdition
2024-11-15
dita:mapPath
bmn1691484839905.ditamap
dita:ditavalPath
obe1474387269547.ditaval
dita:id
fvz1470444150352
lifecycle
latest
Product Category
Teradata Tools and Utilities

An application can use one DBCAREA for all the requests or a separate DBCAREA for each request, or use any combination. This choice is available for either multi-sessions or multi-requests.

If the application is... Then you can...
Facing space limitations Reuse the one DBCAREA. This involves copying the Output Request Ids, saving them, and replacing them when doing a Fetch, Rewind, or Cancel against the same Teradata SQL request.

In other fields, like the processing options or buffer addresses or sizes, to change from one request to another, the previous information must be saved and replaced. Because much less information than the whole DBCAREA is saved, the application can show a significant saving of space at the small cost of unloading and reloading those fields between calls.

Able to spare the space for multiple DBCAREAs Allocate one DBCAREA per concurrent request. The application can show some saving of time at the cost of the space for the extra DBCAREAs.
Multi-threaded Allocate one DBCAREA per thread. This is generally a requirement while using multiple threads, because the sharing of DBCAREAs by multiple threads would cause simultaneous updates to the DBCAREA, mixing session results.