| Pro*COBOL プログラマーズ・ガイド 10gリリース2(10.2) E05652-01 |
|
アプリケーション・プログラムでは、ランタイム・エラーを予測して、そのエラーをリカバリするように対処する必要があります。この章では、エラー・レポートおよびリカバリを詳しく説明します。具体的には、ANSI状態変数SQLCODEおよびSQLSTATE、またはOracle SQLCA(SQLコミュニケーション領域)構造を使用して警告およびエラーを処理する方法を説明します。また、WHENEVER文の使用方法と、Oracle ORACA(Oracle通信領域)構造を使用して問題を診断する方法も説明します。
この章の構成は、次のとおりです。
どのようなアプリケーション・プログラムでも、その大部分をエラー処理に当てる必要があります。エラー処理の主な利点は、エラーが存在していてもプログラムの処理を続行できることです。エラーは設計ミス、コーディングの誤り、ハードウェア障害、誤ったユーザー入力をはじめ、様々な原因で発生します。
潜在的なエラーをすべて予測するのは無理ですが、プログラムにとって意味のある特定の種類のエラーについてアクションを考えることはできます。Pro*COBOLでは、エラー処理とはSQL文の実行エラーを検出してリカバリを図ることを意味します。処理を中断しないかぎり、プリコンパイラはエラーを無視して処理を続行するため、エラーは必ずトラップする必要があります。
値が切り捨てられたことを示す警告やデータの終わりなどの状態の変更も処理できます。表中の該当する行をすべて処理する前にINSERT、UPDATEまたはDELETE文が失敗する場合もあるため、各DML文の後にはエラーおよび警告の状態をチェックすることが非常に重要です。
Pro*COBOLは次のような一般的なエラー処理方法をサポートしています。
プリコンパイラ・オプションMODEは、ANSI/ISOに準拠するかどうかを制御します。MODE={ANSI|ANSI14}の場合、SQLSTATE状態変数をPIC X(5)として宣言します。ANSI SQL89 SQLCODE状態変数も継続してサポートされていますが、新しいプログラムへの使用はお薦めしません。MODE={ORACLE|ANSI13}の場合は、EXEC SQL INCLUDE文を使用して必ずSQLCAを含めてください。1つのプログラムで2つの方法を使用することも可能ですが、通常その必要はありません。
方法の併用の詳細は、「状態変数の組合せ」を参照してください。
SQLCAは、Oracleの警告、エラー番号およびエラーの説明を含むレコードに似たホスト言語データ構造です。Oracle9i は、実行SQL文またはPL/SQL文を実行するたびにSQLCAを更新します。(宣言部の後では、SQLCAの値は未定義になります。)プログラムは、SQLCAに格納されたリターン・コードをチェックして、SQL文の結果を判別できます。SQLCAのチェックには、次の2つの方法があります。
WHENEVER文を使用してSQL文の状態を暗黙的にチェックすると、Pro*COBOLは各実行文の後に自動的にエラー・チェック・コードを挿入します。あるいは、ユーザーが明示的にコードを記述し、SQLCA構造のSQLCODEメンバーの値をテストすることもできます。埋込みSQL INCLUDE文を使用してSQLCAを含めるには、次のようにします。
EXEC SQL INCLUDE SQLCA END-EXEC.
ランタイム・エラーについてSQLCAから得られる情報が十分でない場合、ORACAを使用できます。ORACAには、カーソル統計情報、SQL文のテキスト、特定のオプション設定およびシステム統計情報が格納されます。埋込みSQL INCLUDE文を使用してORACAを含めるには、次のようにします。
EXEC SQL INCLUDE ORACA END-EXEC.
ORACAはオプションであり、MODEの設定に関係なく宣言できます。ORACA状態変数の詳細は、「Oracle通信領域の使用」を参照してください。
MODE=ANSIの場合は、宣言部にANSI SQLSTATE変数を宣言して、明示的または暗黙的なエラー・チェックを実行できます。オプションDECLARE_SECTIONをNOに設定すると、宣言部の外でも宣言できます。
この項では、SQLSTATEの宣言方法を説明します。SQLSTATEは、次の例に示すように、5文字の英数文字列として宣言する必要があります。
* Declare the SQLSTATE status variable. EXEC SQL BEGIN DECLARE SECTION END-EXEC. ... 01 SQLSTATE PIC X(5). ... EXEC SQL END DECLARE SECTION END-EXEC.
SQLSTATEステータス・コードは、2文字のクラス・コードとそれに続く3文字のサブクラス・コードで構成されます。クラス・コード00は正常終了を示し、それ以外のクラス・コードは例外のカテゴリを示します。サブクラス・コード000は特定の例外を示しませんが、それ以外のサブクラス・コードは そのカテゴリの中の特定の例外を示します。たとえば、SQLSTATE値22012は、クラス・コード22(データ例外)およびサブクラス・コード012(ゼロによる除算)で構成されます。
SQLSTATE値の5文字は、それぞれ数字(0〜9)または大文字の英文字(A〜Z)で構成されます。0〜4の範囲の数字、またはA〜Hの範囲の文字で始まるクラス・コードは、事前定義済の状態(SQL92で定義されている)用に確保されています。他のすべてのクラス・コードは実装定義の状態用に確保されています。事前定義済のクラス内では、0〜4の範囲の数字またはA〜Hの範囲の英文字で始まるサブクラス・コードは、事前定義済のサブコンディションを示すために確保されています。その他のサブクラス・コードはすべて、実装定義のサブコンディションを示すために確保されています。図8-1はコード体系を示します。
表8-1に、SQL92によって事前定義済のクラスを示します。
表8-4「SQLSTATEコード」に、エラーとSQLSTATEステータス・コードの対応関係を示します。1つのステータス・コードに複数のエラーが対応する場合もあります。また、ステータス・コードに対応するエラーがない場合もあります(この場合は、表の右端の列は空白になります)。60000〜99999の範囲のステータス・コードは、実装定義です。
Oracle9i では、実行時にプログラムに渡されたステータス情報はSQLコミュニケーション領域(SQLCA)に格納されます。SQLCAはレコードに似たCOBOLデータ構造で、実行SQL文が実行されるたびに更新されます。このため、SQLCAは常に一番最後に実行されたSQL操作の結果を反映しています。SQLCAの各フィールドには、エラー、警告およびステータス情報が格納されます。これらの情報は、SQL文が実行されるたびにOracle9i によって更新されます。SQLCA文の実行結果を確認するには、SQLCA内の変数を調べます。これには、COBOLコードを記述して明示的に調べる方法と、WHENEVER文を使用して暗黙的に調べる方法があります。
MODE={ORACLE | ANSI13}のときはSQLCAは必須です。SQLCAが宣言されていないと、コンパイル時エラーが発生します。MODE={ANSI | ANSI14}のときはSQLCAは必須ではありませんが、SQLCAを宣言しないとWHENEVER SQLWARNING文は使用できません。マルチバイトNCHARホスト変数を使用するときにもSQLCAを含める必要があります。
|
注意: アプリケーションでOracle Netを使用してローカル・データベースおよびリモート・データベースの組合せに同時にアクセスする場合、すべてのデータベースは1つのSQLCAに書き込みます。つまり、データベースごとに異なるSQLCAがあるわけではありません。詳細は、「同時ログイン」を参照してください。 |
SQLCAには、エラー・コード、警告フラグ、イベント情報、処理済行数または診断情報など、SQL文の実行に関する実行時情報が格納されます。
図8-2に、SQLCA内のすべての変数を示します。
SQLCAを宣言するには、次に示すように、(EXEC SQL INCLUDE文を使用して)Pro*COBOLソース・ファイルの宣言部の外に組み込みます。
* Include the SQL Communications Area (SQLCA). EXEC SQL INCLUDE SQLCA END-EXEC.
SQLCAは宣言部の外で宣言する必要があります。
プログラムをプリコンパイルすると、INCLUDE SQLCA文はいくつかの変数宣言に置き換えられます。これらの変数宣言によって、Oracle9i とプログラムとの間の通信が可能になります。
Pro*COBOLのエラー・レポートの基本的なコンポーネントは、SQLCA内のいくつかのフィールドを使用します。
実行SQL文はすべて、SQLCA変数SQLCODEにステータス・コードを戻します。戻されたステータス・コードは、WHENEVER SQLERRORを使用して暗黙的に、またはCOBOLコードを記述して明示的にチェックできます。
警告フラグは、SQLCA変数SQLWARN0〜SQLWARN7に戻されます。戻された警告フラグは、WHENEVER SQLWARNINGを使用するか、COBOLコードを記述することによってチェックできます。警告フラグは、エラーとみなさない実行時の状態を検出する場合に役立ちます。
一番最後に実行されたSQL文で処理された行数が、SQLCA変数SQLERRD(3)に戻されます。OPENカーソルで繰り返されるFETCHについては、フェッチされた行数の実行合計がSQLERRD(3)に格納されます。
Oracle9i は、SQL文を解析してから実行します。つまり実行前に、SQL文に正しい構文ルールが使用され有効なデータベース・オブジェクトを参照しているかを確認します。エラーが見つかると、SQLCA変数SQLERRD(5)にオフセットを格納します。このオフセットは明示的にチェックできます。解析エラーの始まりを示すSQL文中の文字位置がオフセットとして指定されます。先頭の文字位置は0(ゼロ)です。たとえば、オフセットが9の場合、解析エラーの始まりは10番目の文字です。
SQL文に解析エラーがない場合、SQLERRD(5)は0(ゼロ)に設定されます。解析エラーが先頭の文字(文字位置0(ゼロ))から始まっている場合にも、SQLERRD(5)は0(ゼロ)に設定されます。このため、SQLERRD(5)のチェックは、SQLCODEが負の値(エラーが発生したことを示す)の場合にのみ行ってください。
エラー・コードおよびメッセージは、SQLCA変数SQLERRMCに格納されます。たとえば、エラー処理ルーチンに次の文を記述します。
* Handle SQL execution errors. MOVE SQLERRMC TO ERROR-MESSAGE. DISPLAY ERROR-MESSAGE.
格納されるのは、メッセージ・テキストの先頭から70文字までです。70文字を超えるメッセージについては、SQLGLMサブルーチンをコールする必要があります。SQLGLMサブルーチンの詳細は、「エラー・メッセージのテキスト全体の取得」を参照してください。
この項では、SQLCAの構造、そのフィールドおよびフィールドに格納できる値を説明します。
この文字列フィールドは、SQLコミュニケーション領域を示す「SQLCA」に初期化されます。
この整数フィールドには、SQLCA構造の長さ(バイト数)が格納されます。
この整数フィールドには、一番最後に実行されたSQL文のステータス・コードが格納されます。ステータス・コードはSQL処理の結果を表します。コードの値は次のいずれかです。
このサブレコードには、次の2つのフィールドがあります。
この文字列フィールドは、将来の使用に備えて確保されています。
この2進整数の表には6つの要素があります。SQLERRDの各フィールドを説明します。
この表は、それぞれ1文字からなる8つの要素で構成されています。これらの要素は警告フラグとして使用されます。Oracle9i では、フラグに「W」(警告)文字値を割り当ててフラグを設定します。フラグは例外状態の発生を警告します。
たとえば、Oracle9i で切り捨てられた列値を出力ホスト文字変数に割り当てると、警告フラグが設定されます。
SQLWARNの各フィールドを説明します。
この文字列フィールドは、将来の使用に備えて確保されています。
埋込みPL/SQLブロックを実行するPro*COBOLプログラムの場合、SQLCAのフィールドがすべて設定されるわけではありません。たとえば、PL/SQLブロックで複数の行がフェッチされた場合、処理済行数SQLERRD(3)は、実際にフェッチされた行数ではなく、1に設定されます。したがって、PL/SQLブロックを実行した後は、信頼できるSQLCAのフィールドはSQLCODEフィールドおよびSQLERRMフィールドのみになります。
SQLCODEを明示的に宣言し、SQLCAを含めていない場合、MODEの設定に関係なく、SQLGLMを使用してエラー・メッセージのテキスト全体を取得できます。SQLCAには70文字までのエラー・メッセージを格納できます。70文字より長い(またはネストした)エラー・メッセージを取得するには、SQLGLMサブ・ルーチンが必要です。
データベースに接続すると、次の構文を使用してSQLGLMをコールできます。
CALL "SQLGLM" USING MSG-TEXT, MAX-SIZE, MSG-LENGTH
パラメータは次のとおりです。
パラメータはすべて、参照によって渡す必要があります。通常、デフォルトでパラメータ引渡し規則は参照によって引渡されるため、特別な処置は必要ありません。
エラー・メッセージの最大長は、512文字です。これには、エラー・コード、ネストされたメッセージおよび表名や列名などのメッセージ挿入語句を含みます。SQLGLMで戻されるエラー・メッセージの最大長は、MAX-SIZEに指定した値によって決まります。
次の例では、SQLGLMを使用して、エラー・メッセージの最大長を200文字に設定します。
... * Declare variables for the SQL-ERROR subroutine call. 01 MSG-TEXT PIC X(200). 01 MAX-SIZE PIC S9(9) COMP VALUE 200. 01 MSG-LENGTH PIC S9(9) COMP. ... PROCEDURE DIVISION. MAIN. EXEC SQL WHENEVER SQLERROR GOTO SQL-ERROR END-EXEC. ... SQL-ERROR. * Clear the previous message text. MOVE SPACES TO MSG-TEXT. * Get the full text of the error message. CALL "SQLGLM" USING MSG-TEXT, MAX-SIZE, MSG-LENGTH. DISPLAY MSG-TEXT.
この例では、SQLGLMはSQLエラーが発生したときのみにコールされます。SQLGLMをコールする前に、SQLCODEが負の値であることを必ず確認してください。SQLCODEが0(ゼロ)のときにSQLGLMをコールすると、前のSQL文に対応するメッセージ・テキストが戻されます。
DB2には、表示可能な形式のSQLCAを取得するための、DSNTIARというアセンブラ・ルーチンがあります。DB2からOracleへ移行するユーザーのために、Pro*COBOLにもDSNTIARが用意されています。DSNTIARは、ラップを行うSQLGLMとして実装されています。DSNTIARのインタフェースは次のようになります。
CALL 'DSNTIAR' USING SQLCA MESSAGE LRECL
MESSAGEはサイズ240以上のVARCHAR形式の出力メッセージ領域で、LRECLは出力メッセージの長さ(72〜240)が格納されるフル・ワードです。MESSAGE引数の最初のハーフ・ワードには、残りの領域の長さが含まれます。DSNTIARが戻すエラー・コードを次の表に示します。
| エラー・コード | 説明 |
|---|---|
|
0 |
正常に実行しました。 |
|
4 |
指定されたメッセージよりも大きな領域です。 |
|
8 |
論理レコード長(LRECL)が72〜240の範囲外です。 |
|
12 |
メッセージ領域の大きさが十分ではありません(240よりも大きい)。 |
デフォルトでは、Pro*COBOLは可能であればエラーおよび警告状態を無視して処理を続行します。自動状態チェックおよびエラー処理を実行するにはWHENEVER文が必要です。
WHENEVER文を使用すると、Oracle9i がエラー、警告状態または「見つかりません」という状態を検出した場合の処置を指定できます。指定できる処置としては、次の文からの処理の続行、段落のPERFORM、段落への分岐または停止などがあります。
Oracle9i に自動的にSQLCAをチェックさせて、次の状態が存在しないかどうかを調べることができます。
Oracle9i から警告が戻されたか(同時にSQLWARN(1)〜SQLWARN(7)の警告フラグのうちの1つが設定されます)、またはSQLCODEの値が+1403以外の正の値になっていたために、SQLWARN(0)が設定されている状態です。たとえば、切り捨てられた列値が出力ホスト変数に割り当てられると、SQLWARN(1)が設定されます。
MODE={ANSI | ANSI14}のときは、SQLCAの宣言はオプションです。ただし、WHENEVER SQLWARNINGを使用するには、必ずSQLCAを宣言してください。
Oracle9i からエラーが戻された場合、SQLCODEが負の値に設定されます。
フェッチの最後に達すると、SQLCODE値として+1403(またはMODE={ANSI | ANSI14 | ANSI13}またはEND_OF_FETCH=100の場合は+100)が戻されます。これは、検索基準に適合するすべての行がフェッチされるか、検索基準に適合する行が1つもない場合に発生します。
END_OF_FETCHオプションを使用して、MODEマクロ・オプションで使用される値をオーバーライドできます。
END_OF_FETCH = 100 | 1403 (default 1403)
詳細は、「END_OF_FETCH」を参照してください。
WHENEVER文を使用して、次のアクションを指定できます。
可能であれば、プログラムは次の文からの実行を継続します。これはデフォルトの動作で、WHENEVER文を使用しない場合と同じです。状態のチェックを「オフ」にするのに使用できます。
プログラムはネストされたサブプログラムをコールします。サブプログラムの最後に達すると、失敗したSQL文の後の文に制御が渡されます。
プログラムは制御をCOBOL節または段落に渡します。節の最後では、失敗したSQL文の後の文に制御が渡されます。
EXEC SQL WHENEVER <condition> DO PERFORM <section_name> END-EXEC.
プログラムは指定された段落または節に分岐します。
プログラムは実行を停止し、COMMITされていない作業がロールバックされます。
STOPアクションでは、ログオフするまでメッセージは表示されないので注意してください。
WHENEVER文の構文は次のとおりです。
EXEC SQL WHENEVER <condition> <action> END-EXEC.
WHENEVER ... DO PERFORM文を使用するときには、段落または節に対してPERFORM文を実行する場合の通常の規則が適用されます。ただし、THRU句、TIMES句、UNTIL句またはVARYING句は使用できません。
たとえば、次のWHENEVER...DO文は無効です。
PROCEDURE DIVISION. * Invalid statement EXEC SQL WHENEVER SQLERROR DO PERFORM DISPLAY-ERROR THRU LOG-OFF END-EXEC. ... DISPLAY-ERROR. ... LOG-OFF. ...
次に示すのは、WHENEVER SQLERROR DO PERFORM文を使用して特定のエラーを処理する例です。
PROCEDURE DIVISION. MAIN SECTION. MSTART. ... EXEC SQL WHENEVER SQLERROR DO PERFORM INS-ERROR END-EXEC. EXEC SQL INSERT INTO EMP (EMPNO, ENAME, DEPTNO) VALUES (:EMP-NUMBER, :EMP-NAME, :DEPT-NUMBER) END-EXEC. EXEC SQL WHENEVER SQLERROR DO PERFORM DEL-ERROR END-EXEC. EXEC SQL DELETE FROM DEPT WHERE DEPTNO = :DEPT-NUMBER END-EXEC. ... MEXIT. STOP RUN. INS-ERROR SECTION. INSSTART. * Check for "duplicate key value" Oracle9 error IF SQLCA.SQLCODE = -1 ... * Check for "value too large" Oracle9 error ELSE IF SQLCA.SQLCODE = -1401 ... ELSE ... END-IF. ... INSEXIT. EXIT. * DEL-ERROR SECTION. DSTART. * Check for the number of rows processed. IF SQLCA.SQLERRD(3) = 0 ... ELSE ... END-IF. ... DEXIT. EXIT.
各段落でどのようにSQLCA内の変数をチェックし、実行する処理を決定しているか注意してください。
この句はアクション・サブプログラムをコールします。句の構文を次に示します。
EXEC SQL WHENEVER <condition> DO CALL <subprogram_name> [USING <param1> ...] END-EXEC.
次の制限または規則が適用されます。
次に示す例は、サブプログラムLOGONまたはMAINプログラムからエラー・サブプログラムSQL-ERRORをコールするプログラムの例です。DO PERFORM句を使用したときと同様、2つの位置でコードが繰り返されることはありません。
IDENTIFICATION DIVISION. PROGRAM-ID. MAIN. ENVIRONMENT DIVISION. ... PROCEDURE DIVISION. BEGIN-PGM. EXEC SQL WHENEVER SQLERROR DO CALL "SQL-ERROR" END-EXEC. CALL "LOGON". ... IDENTIFICATION DIVISION. PROGRAM-ID. LOGON. DATA DIVISION. WORKING-STORAGE SECTION. 01 USERNAME PIC X(15) VARYING. 01 PASSWD PIC X(15) VARYING. PROCEDURE DIVISION. MOVE "SCOTT" TO USERNAME-ARR. MOVE 5 TO USERNAME-LEN. MOVE "TIGER" TO PASSWD-ARR. MOVE 5 TO PASSWD-LEN. EXEC SQL CONNECT :USERNAME IDENTIFIED BY :PASSWD END-EXEC. DISPLAY " ". DISPLAY "CONNECTED TO ORACLE AS USER: ", USERNAME-ARR. END PROGRAM LOGON. ... IDENTIFICATION DIVISION. PROGRAM-ID. SQL-ERROR COMMON. PROCEDURE DIVISION. EXEC SQL WHENEVER SQLERROR CONTINUE END-EXEC. DISPLAY " ". DISPLAY SQLERRMC. EXEC SQL ROLLBACK WORK RELEASE END-EXEC. END PROGRAM SQL-ERROR. END PROGRAM MAIN.
WHENEVER文は宣言部のため、そのスコープは論理的なものではなく位置的なものになります。WHENEVER文がテストするのは、ソース・ファイルの中でそのWHENEVER文より後に記述されているすべての実行SQL文であり、プログラム・ロジックの流れの中でそのWHENEVER文より後にくる実行SQL文ではありません。したがってWHENEVER文は、テストする最初の実行SQL文の前に指定する必要があります。
WHENEVER文は、同じ条件をチェックする別のWHENEVER文に置き換えられるまで有効です。
WHENEVER文を不注意に使用すると、問題が発生することがあります。たとえば、次のコードは、検索条件を満たす行がないため、DELETE文でNOT FOUND状態を設定すると無限ループに陥ります。
* Improper use of WHENEVER. EXEC SQL WHENEVER NOT FOUND GOTO NO-MORE END-EXEC. PERFORM GET-ROWS UNTIL DONE = "YES". ... GET-ROWS. EXEC SQL FETCH emp_cursor INTO :EMP-NAME, :SALARY END-EXEC. ... NO-MORE. MOVE "YES" TO DONE. EXEC SQL DELETE FROM EMP WHERE EMPNO = :EMP-NUMBER END-EXEC. ...
次の例では、GOTOのターゲットを設定しなおすことによってNOT FOUND状態を適切に処理しています。
* Proper use of WHENEVER. EXEC SQL WHENEVER NOT FOUND GOTO NO-MORE END-EXEC. PERFORM GET-ROWS UNTIL DONE = "YES". ... GET-ROWS. EXEC SQL FETCH emp_cursor INTO :EMP-NAME, :SALARY END-EXEC. ... NO-MORE. MOVE "YES" TO DONE. EXEC SQL WHENEVER NOT FOUND GOTO NONE-FOUND END-EXEC. EXEC SQL DELETE FROM EMP WHERE EMPNO = :EMP-NUMBER END-EXEC. ... NONE-FOUND. ...
多くのPro*COBOLアプリケーションでは、処理している文のテキスト、長さおよびその文に記述されているSQLコマンド(INSERTやSELECTなど)がわかると便利です。これは、動的SQLを使用するアプリケーションでは特に重要です。
ルーチンSQLGLSを使用すると、次の情報が戻されます(このルーチンはSQLLIBランタイム・ライブラリに入っています)。
SQLGLSは、静的SQL文の発行後にコールできます。動的SQL方法1では、SQL文の実行後にSQLGLSをコールできます。動的SQL方法2、3または4では、SQL文の作成後にSQLGLSをコールできます。
SQLGLSをコールするための構文は次のとおりです。
CALL "SQLGLS" USING SQLSTM STMLEN SQLFC.
表8-3に、SQLGLS引数リストのパラメータに使用可能なホスト言語のデータ型を示します。
| パラメータ | データ型 |
|---|---|
|
SQLSTM |
PIC X(n) |
|
STMLEN |
PIC S9(9) COMP |
|
SQLFC |
PIC S9(9) COMP |
パラメータはすべて、参照によって渡す必要があります。通常、デフォルトでパラメータ引渡し規則は参照によって引渡されるため、特別な処置は必要ありません。
パラメータSQLSTMは、SQL文の戻されたテキストを保持する空白埋め(ヌル文字で終了しない)文字バッファです。プログラムでは、このバッファを静的に宣言するか、このバッファに動的にメモリーを割り当てる必要があります。
長さを指定するパラメータSTMLENは、4バイトの整数です。SQLGLSをコールする前に、このパラメータをSQLSTMバッファの実際のサイズ(バイト数)に設定してください。SQLGLSが戻されると、SQLSTMバッファにはSQL文のテキストが格納され、空き部分には空白が埋め込まれます。STMLENは、戻された文のテキストでの実際のバイト数を戻します。(埋め込まれた空白は数えません。)ただし、エラーが発生した場合は、STMLENは0(ゼロ)を戻します。
発生する可能性のあるエラーは次のとおりです。
パラメータSQLFCは、文中のSQLコマンドに対応するSQLファンクション・コードを戻す4バイトの整数です。SQLコマンドの関数コードの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』の表を参照してください。
次の文には、対応するSQLファンクション・コードはありません。
SQLCAは、標準SQLの通信を対象としています。Oracle通信領域(ORACA)もSQLCAと同様の構造ですが、ORACAをプログラムに組み込むとOracle9i 固有の通信を処理できるようになります。SQLCAで提供される情報よりも詳しい実行時情報が必要な場合に、ORACAを使用してください。
ORACAは、問題の診断に役立つのみでなく、SQL文エグゼキュータやカーソル・キャッシュ(カーソル管理のために確保されているメモリー領域)などのリソースをプログラムがどのように使用しているかを監視する場合にも使用できます。
ORACAにはオプション設定、システム統計および拡張診断機能が含まれています。図8-3に、ORACAのすべての変数を示します。
ORACAを宣言するには、次に示すように、(EXEC SQL INCLUDE文を使用して)Pro*COBOLソース・ファイルの宣言部の外に組み込みます。
* Include the Oracle Communications Area (ORACA). EXEC SQL INCLUDE ORACA END-EXEC.
ORACAを使用可能にするには、ORACAプリコンパイラ・オプションをYESに設定する必要があります。これには、コマンドラインまたは構成ファイルに次のように入力します。
ORACA=YES
またはインラインで次のように指定します。
EXEC Oracle OPTION (ORACA=YES) END-EXEC.
その後、ORACA内のフラグを設定することによって、適切なランタイム・オプションを選択する必要があります。ORACAを使用可能にすると実行時のオーバーヘッドが増加することになるため、ORACAの使用はオプションになっています。デフォルトの設定はORACA=NOです。
ORACAにはいくつかのオプション・フラグがあります。これらのフラグを設定するには、オプション・フラグに0(ゼロ)以外の値を割り当てます。オプション・フラグの設定により、次の処理を行えます。
次の説明はオプションを選択するときの参考になります。
この項では、ORACAの構造、フィールドおよびフィールドに格納できる値を説明します。
この文字列フィールドは、Oracle通信領域を示すORACAに初期化されます。
この整数フィールドには、ORACAデータ構造の長さ(バイト数)が格納されています。
マスターDEBUGフラグ(ORADBGF)が設定されているときにこのフラグを設定すると、カーソル操作のたびにカーソル・キャッシュの一貫性をあらかじめチェックできます。
ランタイム・ライブラリでは一貫性チェックが行われ、エラー・メッセージが出力される場合もあります。エラー・メッセージのリストは、『Oracle Databaseエラー・メッセージ』を参照してください。
このフラグは次のいずれかを設定します。
| 設定 | 説明 |
|---|---|
|
0 |
キャッシュ一貫性チェックを使用禁止にします(デフォルト)。 |
|
1 |
キャッシュ一貫性チェックを使用可能にします。 |
このマスター・フラグを使用すると、DEBUGオプションをすべて選択できます。このフラグには次のいずれかを設定します。
| 設定 | 説明 |
|---|---|
|
0 |
すべてのDEBUG処理を使用禁止にします(デフォルト)。 |
|
1 |
DEBUG操作を使用可能にします。 |
マスターDEBUGフラグ(ORADBGF)が設定されているときにこのフラグを設定すると、Pro*COBOLが動的にメモリーの割当てや解放を行うたびにランタイム・ライブラリを使用してヒープの一貫性をチェックできます。これはメモリー障害を起こすプログラムの不具合を検出するのに役立ちます。
このフラグはCONNECTコマンドを発行する前に設定する必要があります。また、このフラグは一度設定すると解除できなくなります。つまり、設定後にこのフラグの変更要求があっても無視されます。このフラグには次のいずれかを設定します。
| 設定 | 説明 |
|---|---|
|
0 |
ヒープの一貫性チェックを使用可能にします(デフォルト)。 |
|
1 |
ヒープの一貫性チェックを使用禁止にします。 |
このフラグを使用すると、現行のSQL文のテキストを保存するタイミングを指定できます。このフラグには次のいずれかを設定します。
| 設定 | 説明 |
|---|---|
|
0 |
SQL文のテキストを保存しません(デフォルト)。 |
|
1 |
SQLERRORのSQL文のテキストのみ保存します。 |
|
2 |
SQLERRORまたはSQLWARNINGのSQL文のテキストのみ保存します。 |
|
3 |
常にSQL文のテキストを保存します。 |
SQL文のテキストは、ORASTXTの名前のORACAサブレコードに保存されます。
ORACAは高度な診断情報を提供します。次の変数によってエラーの位置をすばやく特定できます。
このサブレコードは、問題のあるSQL文を見つけるのに役立ちます。Oracle9i で解析された最後のSQL文のテキストを保存できます。このサブレコードには、次の2つのフィールドがあります。
| 設定 | 説明 |
|---|---|
|
ORASTXTL |
この整数フィールドには、現行のSQL文の長さが格納されます。 |
|
ORASTXTC |
この文字列フィールドには、現行のSQL文のテキストが格納されます。先頭から最長70文字分のテキストが保存されます。 |
Pro*COBOLによって解析される文(CONNECT、FETCHまたはCOMMITなど)は、ORACAには保存されません。
このサブレコードによって、現行のSQL文が入っているファイルを識別できます。これにより、1つのアプリケーション用に複数のファイルをプリコンパイルした場合にエラーを見つけやすくなります。このサブレコードには、次の2つのフィールドがあります。
| 設定 | 説明 |
|---|---|
|
ORASFNML |
この整数フィールドには、ORASFNMCに格納されているファイル名の長さが格納されます。 |
|
ORASFNMC |
この文字列フィールドには、ファイル名が格納されます。先頭から最長70文字分が保存されます。 |
この整数フィールドにより、現行のSQL文が記述されている行(またはその近くの行)を識別できます。
次に説明する一連の変数を使用して、カーソル・キャッシュ統計情報を収集できます。これらの変数は、プログラムがCOMMITまたはROLLBACK文を発行するたびに自動的に設定されます。内部的には、CONNECTされているデータベース別にこの変数のセットがあります。ORACAの現在の設定値は、最後にコミットまたはロールバックされたデータベースに関する値です。
この整数フィールドには、プログラムの実行中にMAXOPENCURSORSに設定された最大の値が記録されます。
この整数フィールドには、プログラムの要求によってオープンされたカーソルの最大数が記録されます。MAXOPENCURSORSの設定が低すぎると、この値がORAHOCの値を上回ることがあります。この場合、Pro*COBOLによってカーソル・キャッシュが強制的に拡張されます。
この整数フィールドには、プログラムの要求によって現在オープンしているカーソル数が記録されます。
この整数フィールドには、プログラムの要求によって再度割り当てられたカーソル・キャッシュの数が記録されます。この数値はカーソル・キャッシュのスラッシングの程度を示し、できるだけ低く抑える必要があります。
この整数フィールドには、プログラムの要求によって解析されたSQL文の数が記録されます。
この整数フィールドには、プログラムの要求によって実行されたSQL文の数が記録されます。この数値のORANPRの数値に対する割合は、できるかぎり高く保つ必要があります。つまり、不要な再解析は回避する必要があります。ヘルプについては、付録C「パフォーマンス・チューニング」を参照してください。
次のプログラムは、部門番号の入力を要求し、その部門に所属している各従業員の名前と給与を2つの表のいずれかに挿入して、ORACAからの診断情報を表示します。
IDENTIFICATION DIVISION. PROGRAM-ID. ORACAEX. ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE SECTION. EXEC SQL INCLUDE SQLCA END-EXEC. EXEC SQL INCLUDE ORACA END-EXEC. EXEC ORACLE OPTION (ORACA=YES) END-EXEC. EXEC SQL BEGIN DECLARE SECTION END-EXEC. 01 USERNAME PIC X(20). 01 PASSWORD PIC X(20). 01 EMP-NAME PIC X(10) VARYING. 01 DEPT-NUMBER PIC S9(4) COMP. 01 SALARY PIC S9(6)V99 DISPLAY SIGN LEADING SEPARATE. EXEC SQL END DECLARE SECTION END-EXEC. PROCEDURE DIVISION. DISPLAY "Username? " WITH NO ADVANCING. ACCEPT USERNAME. DISPLAY "Password? " WITH NO ADVANCING. ACCEPT PASSWORD. EXEC SQL WHENEVER SQLERROR GOTO SQL-ERROR END-EXEC. EXEC SQL CONNECT :USERNAME IDENTIFIED BY :PASSWORD END-EXEC. DISPLAY "Connected to Oracle". * -- set flags in the ORACA * -- enable debug operations MOVE 1 TO ORADBGF. * -- enable cursor cache consistency check MOVE 1 TO ORACCHF. * -- always save the SQL statement MOVE 3 TO ORASTXTF. DISPLAY "Department number? " WITH NO ADVANCING. ACCEPT DEPT-NUMBER. EXEC SQL DECLARE EMPCURSOR CURSOR FOR SELECT ENAME, SAL + NVL(COMM,0) FROM EMP WHERE DEPTNO = :DEPT-NUMBER END-EXEC. EXEC SQL OPEN EMPCURSOR END-EXEC. EXEC SQL WHENEVER NOT FOUND GOTO NO-MORE END-EXEC. LOOP. EXEC SQL FETCH EMPCURSOR INTO :EMP-NAME, :SALARY END-EXEC. IF SALARY < 2500 EXEC SQL INSERT INTO PAY1 VALUES (:EMP-NAME, :SALARY) END-EXEC ELSE EXEC SQL INSERT INTO PAY2 VALUES (:EMP-NAME, :SALARY) END-EXEC END-IF. GO TO LOOP. NO-MORE. EXEC SQL CLOSE EMPCURSOR END-EXEC. EXEC SQL WHENEVER SQLERROR CONTINUE END-EXEC. EXEC SQL COMMIT WORK RELEASE END-EXEC. DISPLAY "(NO-MORE.) Last SQL statement: ", ORASTXTC. DISPLAY "... at or near line number: ", ORASLNR. DISPLAY " ". DISPLAY " Cursor Cache Statistics". DISPLAY "-------------------------------------------". DISPLAY "Maximum value of MAXOPENCURSORS ", ORAHOC. DISPLAY "Maximum open cursors required: ", ORAMOC. DISPLAY "Current number of open cursors: ", ORACOC. DISPLAY "Number of cache reassignments: ", ORANOR. DISPLAY "Number of SQL statement parses: ", ORANPR. DISPLAY "Number of SQL statement executions: ", ORANEX. STOP RUN. SQL-ERROR. EXEC SQL WHENEVER SQLERROR CONTINUE END-EXEC. EXEC SQL ROLLBACK WORK RELEASE END-EXEC. DISPLAY "(SQL-ERROR.) Last SQL statement: ", ORASTXTC. DISPLAY "... at or near line number: ", ORASLNR. DISPLAY " ". DISPLAY " Cursor Cache Statistics". DISPLAY "-------------------------------------------". DISPLAY "MAXIMUM VALUE OF MAXOPENCURSORS ", ORAHOC. DISPLAY "Maximum open cursors required: ", ORAMOC. DISPLAY "Current number of open cursors: ", ORACOC. DISPLAY "Number of cache reassignments: ", ORANOR. DISPLAY "Number of SQL statement parses: ", ORANPR. DISPLAY "Number of SQL statement executions: ", ORANEX. STOP RUN.
SQLSTATEのコード、その意味および戻されるエラーを次の表に示します。
MODE={ANSI | ANSI14}のときは、状態変数の動作は次の設定によって変わります。
表8-5および表8-6に、ASSUME_SQLCODE=NOおよびASSUME_SQLCODE=YESのときの各状態変数の組合せの動作結果をそれぞれ示します。
両方の表には次のことが適用されます。DECLARE_SECTION=NOの場合は、状態変数の宣言はすべて(宣言部の)内部にあるものとして扱われます。
ASSUME_SQLCODE=YESは、DECLARE_SECTION=NOと併用しないでください。
|
![]() Copyright © 2007 Oracle Corporation. All Rights Reserved. |
|