DBFABTは、DBCHCLのAbort Request関数です。
DBFABTは、現在の開始要求と、その要求が埋め込まれたトランザクションのアボートを試みます。 進行中の要求をアボートするために、非同期的に使用されます。
どのように機能するか
- アプリケーションでオプションの更新を要求していた場合には、オプションの設定/検証ロジックを実行します。
- 指定された要求がデータベース上でアクティブな場合は、AbortRequestメッセージを送って呼び出し側に戻ります。アクティブでない場合は、単にエラー コードを返します。
アボートの送信
- DBFABT関数のDBCHCLを呼び出します。
- その戻りコードがゼロであることを確認します。
ゼロの戻りコードはアボートが送られたことを示します。 これはアボートが成功したことを保証するものではありません。アボートは応答と「行き違いになる」ことがあります。 アボートが成功したかどうかを判定するためには、アプリケーション プログラムで、受け取った応答の最初のパーセルも見なければなりません。
成功するアボート操作
- DBFABT関数のDBCHCLを呼び出します。
- その戻りコードがゼロであることを確認します。
- DBFFET関数のDBCHCLを呼び出します。
- その戻りコードがゼロであることを確認します。
- その最初のパーセルがFailureであることを確認します。
- 失敗コードが'user abort'(ユーザーによるアボート)(3110)であることを確認します。
- DBFERQ関数のDBCHCLを呼び出します。
- その戻りコードがゼロであることを確認します。
非同期のアボート
非同期のアボートが応答(スプール ファイル)を完了する前にデータベースに到達した場合、データベースは、元のTeradata SQLリクエストをアボートし、この要求が組み込まれていた(明示的または暗黙の)トランザクションがあればこれをロールバックし、さらにFailureパーセルを元の要求に対する応答として送ります。
トランザクションがロールバックされた場合には、そのトランザクションによって変更されたデータベースは、そのトランザクションが実行依頼されなかった時点での状態に戻されます。しかし、すでに完了されたTeradata SQLリクエストに対するTeradata SQL応答のファイルは、破棄されません。これらのファイルは、DBFERQ関数のDBCHCLを呼び出して要求がクローズされるまで、引き続きデータベースに残っています。
非同期のアボートが応答を完了した後でデータベースに到達した場合には、クライアントは元の要求に対する元の応答パーセルを受け取ります。アボートは実行されません。
1つの要求をアボートするためには、アプリケーション プログラムで、その要求のセッションidと要求idをDBCAREAに指定し、関数コードをアボートに設定してDBCHCLを呼び出します。 複数のセッションを使用しているときに2つ以上の要求をアボートする場合には、アプリケーションでこれらのステップを要求ごとに繰り返します。
DBFABT(アボート)は、Wait For Responseの設定値によって影響を受けません。
アプリケーション プログラムでトランザクションを進行させており、そのトランザクションが要求と要求の間の状態にある場合には、Teradata SQLのROLLBACK文から成る要求を用いてDBFIRQ(要求の開始)関数のDBCHCLを呼び出して、非同期のアボートを実行依頼します。
読み取りおよび使用され、保存されない値
Wait Across Crash、Tell About Crash、Return time、およびWait For Responseの値は、読み取られて使用されます。ただし、保存されません。
インターフェース
DBFABTインターフェースは、次のとおりです。
関数: | DBFABT - Abort Request |
目的: | 現在の活動要求の「アボート」を試みる |
パラメータ: |