ケース1: 通知および待機 - Call-Level Interface Version 2

Teradata® Call-Level Interfaceバージョン2リファレンス - ワークステーション接続システム

Product
Call-Level Interface Version 2
Release Number
17.10
Published
2021年6月
ft:locale
ja-JP
ft:lastEdition
2021-09-23
dita:mapPath
ja-JP/ttt1608578409164.ditamap
dita:ditavalPath
ja-JP/ttt1608578409164.ditaval
dita:id
B035-2418
Product Category
Teradata Tools and Utilities
DBCHINIを呼び出した後で、クラッシュ/遅延のオプションが次のように設定されている場合には、以下のようになります。
  • Tell About Crash(またはTell Across Crash)が'Y'
  • Wait Across Crash(またはWait Across Delay)が'Y'
オプションがこの組み合わせであれば、データベースのクラッシュまたはAPリセットを次のように扱うことができます。
  1. アプリケーションで、何らかの関数のDBCHCLを呼び出します。
  2. DBCHCLからの情報を受け取る前か受け取ったあとでデータベースがクラッシュ、またはAPがリセットします。
  3. CLIは、戻りコードをEM_DBC_CRASH_BまたはEM_DBC_CRASH_Aとして制御をアプリケーション プログラムに戻します。
  4. アプリケーション プログラムは、クラッシュ/遅延の可能性をユーザーに通知し、待機するか切断するかを尋ねることができます。
  5. 待機と仮定した場合、アプリケーション プログラムは、Fetch関数のDBCHCLを呼び出します。
  6. データベースの再始動、またはAPのリセットが完了します。
  7. アプリケーションで、次のようなFetchの結果を入手します。
    • データベースは、そのリクエスト番号のリクエストについては何も知りません(エラー コード2825のErrorパーセル)
    • データベースは、そのリクエストをアボートしました(失敗コード2828のFailureパーセル)
    • リクエストは正常に完了しましたが、応答は喪失しました(エラー コード2826のErrorパーセル)
  8. アプリケーション プログラムで、アプリケーションにとって適切な処置をとります。

リクエストを再び実行依頼しなければならない場合には、リクエストを実行依頼する前にリクエストのコピーを保存しておきます。 トランザクションを再び実行依頼しなければならない場合には、トランザクションが複数のリクエストにまたがっていれば、そのトランザクション内の各リクエストのコピーを保存しておきます。

「通知および待機」は、端末用アプリケーションにおいて、著しく長い応答時間と、まれに起こりうるデータベースのクラッシュ、APリセットを区別するのに有効な場合があります。