ABT (Abort) attempts to abort a request and the transaction in which it is embedded. This is known as an asynchronous abort.
Abort may be used within an External Stored Procedure to indicate that the results of a request initiated with the DBCAREA Return-result-to option will not be reflected to the CALLer or the application.
- If the Return Code is 0, the abort has been sent to the Teradata Database. However, 0 does not mean the request has been aborted. The application must perform FET to check the final disposition of the original request and ERQ to release the request context.
- If the abort reaches the Teradata Database before it completes the request, the request will be aborted and the containing transaction rolled back. Storage associated with the request is kept until ERQ is issued for the request.
- If the abort reaches the Teradata Database after the request has completed, the abort is ignored.
- If the application has an active transaction and is between requests, issue Initiate Request with a ROLLBACK statement rather than calling ABT to perform the abort.
- If the session is running in Two-phase commit mode, ABT ensures that the current session is aborted at syncpoint. This occurs even if the abort had no effect (for example, if the request completed before ABT could abort it).
DBCAREA Input Fields
Before using the Abort function, the application must set the DBCAREA fields in the first table and may optionally set those in the second table depending on the application's requirements.
|DBCAREA Input Fields Required for the Abort Function|
|DBCAREA Input Fields Optional for the Abort Function|
DBCAREA Output Fields
Upon completion of the Abort function, CLIv2 will always set DBCAREA fields in the table.
|DBCAREA Output Fields always set by the Abort Function|