DECLARE CURSOR ステートメント

DECLARE CURSOR ステートメントは、カーソルを定義します。

呼びかけ DECLARE CURSOR

このステートメントは、アプリケーション・プログラムに組み込む方法のみ可能です。これは、実行可能ステートメントではありません。 Java™では指定できません。

承認 DECLARE CURSOR

カーソルの SELECT ステートメントで指定したそれぞれの表またはビューについて、特権セットに、少なくとも次のいずれかが含まれていなければいけません。

SELECT 特権
オブジェクトの所有権
対応するデータベースに対する DBADM 権限 (表のみ)
SYSADM 権限
SYSCTRL 権限 (カタログ表のみ)
DATAACCESS 権限

SELECT ステートメントに SQL データ変更ステートメントが含まれている場合、そのステートメントの許可要件は DECLARE CURSOR ステートメントにも適用されます。

カーソルの SELECT ステートメントは、以下のいずれかです。

ステートメント名で識別される準備済み SELECT ステートメント
指定されたSELECT文

ステートメント名を指定する場合:

特権セットは、DYNAMICRULESの動作（実行、バインド、定義、または呼び出し）によって決定され、表1 にまとめられています。（これらの動作の詳細については、それらを決定するDYNAMICRULESバインドオプション値の一覧を含め、「Authorization IDs and dynamic SQL」を参照してください。）
許可検査は、SELECT ステートメントが準備されたときに行われます。
SELECT ステートメントが正しく準備されなければ、カーソルはオープンできません。

SELECT ステートメントを指定する場合:

特権セットは、プランまたはパッケージ所有者の許可 ID が持つ特権から構成されます。
VALIDATE(BIND) を指定してプランまたはパッケージをバインドする場合、許可検査はバインド時に行われ、必要な特権が存在しなければバインドは失敗します。
VALIDATE(RUN) を指定してプランまたはパッケージをバインドする場合、許可検査はバインド時に行われますが、必要なすべての特権がその時点で存在していなければならないというわけではありません。バインド時にすべての特権が存在していれば、カーソルのオープン時に許可検査は行われません。バインド時に存在しない特権があった場合には、作業単位内でカーソルが初めてオープンされるときに、許可検査が行われます。必要な特権が存在しない場合、OPEN は失敗します。

構文 DECLARE CURSOR

注:

¹ 同一の条項は、複数回指定してはならない。

保持性:

リターン性：

rowset-positioning:

説明の対象: DECLARE CURSOR

cursor-name

カーソルの名前を指定します。この名前は、ソース・プログラム内で既に宣言されているカーソルを示すものであってはなりません。この名前は通常は VARCHAR(128) ですが、カーソルが WITH RETURN を指定して定義されている場合、名前は VARCHAR(30) に制限されます。

NO SCROLL または SCROLL

カーソルが、両方向スクロール・カーソル、または順方向カーソルのどちらかを指定します。

NO SCROLL

カーソルが順方向カーソルであることを指定します。これはデフォルトです。

SCROLL

カーソルが両方向スクロール・カーソルであることを指定します。両方向スクロール・カーソルの場合、カーソルが挿入、更新、または削除を認識するかどうかは、カーソルに対して有効になっているカーソル・センシティビティー・オプションによって決まります。センシティビティー・オプションを指定しない場合は、ASENSITIVE がデフォルトです。

ASENSITIVE

カーソルが可能な限りセンシティブ・カーソルになるように指定します。これはデフォルトです。

ASENSITIVE として定義されたカーソルは、インセンシティブまたはセンシティブ動的のどちらかになり、センシティブ静的にはなりません。 GET DIAGNOSTICS ステートメントまたは SQLCA を使用してカーソルの有効な感度をアプリケーションに返す方法については、 OPEN ステートメントを参照してください。

カーソルのセンシティビティーがアクセス・パスの選択の要因になっています。 ASENSITIVE と指定するのではなく、必要とするセンシティビティー・レベルを明示的に指定してください。

INSENSITIVE

カーソルが、結果表の元になっている行に対する挿入、アップデート、削除に影響されないように指定します。結果として、結果表のサイズ、行の順序、および各行の値は、カーソルがオープンされた後は変更されません。また、カーソルは読み取り専用です。 SELECT ステートメント、または PREPARE ステートメントの attribute-string には FOR UPDATE 文節を指定できず、またカーソルを位置付け UPDATE や位置付け DELETE のために使用することはできません。

SENSITIVE

結果表がマテリアライズされた後でデータベースに対して行われた変更にカーソルがセンシティブであるように指定します。カーソルは、そのカーソルを使用して行われる更新と削除 (つまり、同じカーソルを使用した位置付け UPDATE と位置付け DELETE) に常にセンシティブです。行の現行値が select-statement または statement-name の条件を満たさなくなると、その行はカーソルから可視ではなくなります。結果表の行が基礎となる基本表から削除されると、行はカーソルから可視ではなくなります。

Db2 がカーソルに変更を反映できない場合、OPEN CURSORのバインド時にエラーが発生します。 Db2 カーソルが暗黙的に読み取り専用になった場合、変更をカーソルに反映させることができません。例えば、SELECT ステートメントの FROM 文節に複数の表またはビューが指定されているときのように、結果表をマテリアライズしなければならない場合です。暗黙的な読み取り専用カーソルとなる条件の現在のリストは、「読み取り専用カーソル」を参照してください。

デフォルトは DYNAMIC です。

DYNAMIC

カーソルの結果表が動的であることを指定します。つまり、基礎表の行が挿入されたり削除されたりすると、結果表のサイズはカーソルのオープン後に変化する可能性があり、行の順序が変化する可能性があります。カーソルと同じアプリケーション・プロセスによって実行されるステートメントによって挿入、削除、または更新される行は、即時にカーソルから可視になります。他のアプリケーション・プロセスによって実行されたステートメントによって挿入、削除、または更新された行は、ステートメントのコミット後にのみ可視になります。 ORDER BY 文節の列が、カーソルまたはプロセス外部の手段によって更新される場合、次の FETCH ステートメントは、更新された行が削除されて結果表の正しい位置に再挿入された場合と同様に動作します。位置付け UPDATE の時点で、カーソルは元の位置の次にある行の前に置かれ、現在行はなくなり、見かけ上は行が移動したようになります。

SENSITIVE DYNAMIC カーソルが不可能な場合は、エラーが戻されます。例えば、一時表が必要な場合はエラーが戻されます。 SENSITIVE DYNAMIC として定義されるカーソルの SELECT ステートメントには、SQL データ変更ステートメントを含めることはできません。

変更の開始機密性の高い動的カーソルでは、最外周のフルセレクトに対してオフセット句とフェッチ句を指定してはなりません。変更の終わり

STATIC

カーソルのオープン後は、結果表のサイズおよび行の順序が変わらないことを指定します。基礎表に挿入される行は、行がどのように挿入されても、結果表には追加されません。 ORDER BY 文節の列が既にマテリアライズされている行で更新される場合、結果表の行は移動しません。結果表が更新可能である場合には、位置付け UPDATE および位置付け DELETE を行うことができます。 SENSITIVE STATIC として定義されるカーソルの SELECT ステートメントには、SQL データ変更ステートメントを含めることはできません。

STATIC カーソルは、位置付け UPDATE または位置付け DELETE を用いるこのカーソルにより行われた変更に対して、可視性があります。このカーソルの外で行われたコミット済みの変更は、FETCH ステートメントの SENSITIVE オプションを指定して見ることができます。 FETCH SENSITIVE を指定すると、結果表にホール ができます (つまり、結果表とその基本表の間に違いがあるということです)。カーソルの基本表内の更新された行が SELECT ステートメントの述部条件を満たさなくなってしまった場合、結果表に更新ホールができます。カーソルの行が基本表で削除された場合、結果表に削除ホールができます。 FETCH SENSITIVE が更新ホールを検出すると、データは戻されず (警告が出されます)、カーソルは更新ホールの位置にとどまります。 FETCH SENSITIVE が削除ホールを検出すると、データは戻されず (警告が出されます)、カーソルは削除ホールの位置にとどまります。

カーソルによる更新は、行を自動的に再度フェッチします。この再フェッチは、更新によりホールが作成される可能性があることを意味します。再度取り出された行も、トリガーが同じ行を更新した結果として、変更を反映します。これらの変更を反映して、行のデータの整合性を保つことは重要です。

SENSITIVE STATIC カーソルの select-statement または statement-name の WHERE 文節で非 deterministic 関数 (組み込みまたはユーザー定義) を使用すると、誤った結果となる可能性があります。この状況は、 Db2 が一時的な結果テーブルを構築し、FETCH INSENSITIVE文に対してこのテーブルから行を取得するため発生します。 Db2 がFETCH SENSITIVE文を処理する際には、行が基になるテーブルから取得され、条件が再評価されます。非 deterministic 関数を使用すると、同じ行の各 FETCH SENSITIVE で異なる結果になる可能性があり、行が一致しなくなったと見なされることになります。

SENSITIVE STATIC SCROLL カーソルでの FETCH INSENSITIVE は、前の FETCH SENSITIVE ステートメントが既にその行をリフレッシュしていない限り、カーソルの外で行われた変更にセンシティブではありません。ただし、カーソルによる位置付け UPDATE と位置付け DELETE の変更は可視です。

STATIC カーソルは、挿入にインセンシティブです。

WITHOUT HOLD または WITH HOLD

コミット操作の結果として、カーソルがクローズされることを回避するかどうかを指定します。

WITHOUT HOLD

コミット操作の結果としてカーソルをクローズすることを回避しません。これはデフォルトです。

WITH HOLD

コミット操作の結果としてカーソルをクローズすることを回避します。 WITH HOLD を指定して宣言されたカーソルは、以下のいずれかに当てはまる場合にはコミット時にクローズされます。

カーソルに関連付けられた接続が解除ペンディング状況になっている。
DISCONNECT(AUTOMATIC) バインド・オプションが使用されている。
WITH HOLD オプションが無視される環境である。

WITH HOLD を指定した場合、コミット操作は、現行の作業単位にあるすべての変更をコミットします。例えば、順方向カーソルの場合は、コミット操作の前にカーソルが置かれていた行の次にある行にカーソルを置くために、COMMIT ステートメントの後に初期 FETCH ステートメントが必要です。

SELECT ステートメント内の SQL データ変更ステートメントに対しては、WITH HOLD は効果がありません。 COMMIT を実行すると、カーソルが WITH HOLD として宣言されたかどうかに関係なく、SQL データ変更ステートメントによって行われた変更がコミットされます。

CONNECT (タイプ 1) またはロールバック操作によって、カーソルはすべて暗黙的にクローズされます。 WITH HOLD が無視される場合、または指定されていない場合には、コミット操作によってもカーソルは暗黙的にクローズされます。

CICS® または IMS の非メッセージ駆動型プログラムでWITH HOLDで宣言されたカーソルは、カーソルが以前の作業単位で開かれており、現在の作業単位でデータベースに変更が加えられていない場合、ロールバック操作によって閉じられることはありません。 CICS と IMS が、nullの作業単位に対するロールバック要求を Db2 にブロードキャストしないため、カーソルを閉じることができません。

コミット操作を行う前にカーソルがクローズされると、WITH HOLD オプションなしでカーソルを宣言した場合と同じ結果になります。

IMS メッセージ駆動型プログラム（MPP、IFP、メッセージ駆動型BMP）では、WITH HOLDは無視されます。 WITH HOLDは、 CICS 擬似会話型プログラムにおいて、タスク終了（EOT）までカーソル位置を維持します。

WITH HOLD を使用してカーソルを宣言する際の制限の詳細については、「保留カーソルと非保留カーソル」を参照してください。

WITHOUT RETURN または WITH RETURN

プロシージャーから戻される結果セットとして、カーソルの結果表を使用するかどうかを指定します。 statement-name が指定されている場合、デフォルトはステートメントの対応する準備属性です。それ以外の場合は、デフォルトは WITHOUT RETURN。

WITHOUT RETURN

カーソルの結果表を、プロシージャーから戻される結果セットとして使用しないことを指定します。

WITH RETURN

カーソルの結果表を、プロシージャーから戻される結果セットとして使用することを指定します。 WITH RETURN は、プロシージャーのソース・コード内に DECLARE CURSOR ステートメントが含まれている場合にのみ関係します。その他の場合、プリコンパイラーがこの節を受け入れる可能性はありますが、その節に効果はありません。

WITH RETURN TO CALLER 文節を使用して宣言されたカーソルが、プログラムまたはルーチンの終了時にオープンしたままになっている場合、そのカーソルはそのプログラムまたはルーチンから結果セットを定義します。プログラムまたはルーチンからの結果セットにしないカーソルをクローズするには、CLOSE ステートメントを使用します。 Db2 は、WITH RETURN句を使用して宣言されていないカーソルを自動的にクローズしますが、アプリケーションの移植性を高めるには、CLOSE文の使用が推奨されます。

順方向カーソルの場合、結果セットの内容は、現行カーソル位置から結果表の最後までの行すべてです。両方向スクロール・カーソルの場合、結果セットの内容は結果表の行すべてです。

TO CALLER

カーソルが結果セットをプロシージャーの呼び出し元に戻すことができることを指定します。呼び出し元は、DECLARE CURSOR ステートメントを含むプロシージャーを呼び出す SQL CALL ステートメントを実行したプログラムまたはルーチンです。例えば、呼び出し元がプロシージャーならば、結果セットはプロシージャーに戻されます。また、呼び出し側がクライアント・アプリケーションであるなら、そのクライアント・アプリケーションに結果セットが返されます。

ステートメントがプロシージャーのソース・コードに含まれている場合に、WITH RETURN TO CALLER は、カーソルを結果セット・カーソルとして使用できることを指定します。結果セット・カーソルは、カーソルの結果表がプロシージャーから返される場合に使用されます。 TO CALLER の指定はオプションです。

その他の場合はこの文節が無視され、カーソルは、結果セット・カーソルとして使用できません。

TO CLIENT

カーソルが結果セットをクライアント・アプリケーションに戻すことができることを指定します。このカーソルは、中間ネスト・プロシージャーからは参照できません。関数またはトリガーがそのプロシージャーを呼び出す場合 (直接または間接のいずれか)、結果セットをクライアントに戻すことはできず、プロシージャーの終了後にカーソルはクローズされます。

行セット位置合わせ

カーソルに対する単一の FETCH ステートメントによって、複数のデータ行に行セットとしてアクセスできるかどうかを指定します。デフォルトは WITHOUT ROWSET POSITIONING です。

WITHOUT ROWSET POSITIONING: 行位置付け FETCH ステートメントのみにカーソルを使用できるように指定します。カーソルはそれぞれの FETCH ステートメントごとに単一行を戻し、このカーソルの FETCH ステートメントに対して FOR n ROWS 文節は指定できません。 WITHOUT ROWSET POSITIONING または単一行アクセスは、データベース・エンジンからデータをフェッチする方法に関係します。リモート・アクセスの場合は、データがブロック化され、クライアントにブロック単位で戻される場合があります。
ロウセット位置決め付き: 行位置付け、または行セット位置付け FETCH ステートメントにカーソルを使用できるように指定します。このカーソルを使用すると、単一の FETCH ステートメントによって単一行または複数行 (行セットとして) のどちらも戻すことができます。 ROWSET POSITIONING は、データベース・エンジンからデータをフェッチする方法に関係します。リモート・アクセスの場合は、限定行があれば、少なくとも 1 行が行セットとして戻されます。行セットのサイズは、FETCH ステートメントに指定された行数、および限定行の数によって異なります。データはブロック化され、クライアントにブロック単位で戻される場合があります。
Db2 REXXアプリケーションは、WITH ROWSET POSITIONINGで宣言されたカーソルをサポートしていません。 Db2 REXXアプリケーションのSELECT文でカーソルを使用できるようにするには、行位置指定または行セット位置指定のFETCH文で使用できるように、SELECT文のPREPARE文の属性文字列でWITH ROWSET POSITIONINGを指定します。

select文

カーソルの結果表を指定します。 select-statement の説明については select-statement を参照してください。

SELECT文には、パラメータマーカーを含めることはできません（REXXを除く）。ただし、ホスト変数の参照を含めることはできます。 REXX以外のホスト言語では、ホスト変数の宣言はソースプログラムのDECLARE CURSOR文より前に記述する必要があります。 REXXでは、ホスト変数の代わりにパラメータマーカーを使用し、ステートメントを準備する必要があります。

OPEN ステートメントの USING 文節を使用すると、DECLARE CURSOR ステートメント内でステートメントの一部として指定された、ホスト変数またはパラメーター・マーカーの値をオーバーライドするホスト変数を指定できます。

カーソルが SENSITIVE DYNAMIC または SENSITIVE STATIC と定義されている場合、SELECT 文には SQL データ変更文を含めてはなりません。

変更の開始 SELECT文には、VALUES句であるFULLSELECTを含めてはなりません。変更の終わり

両方向スクロール・カーソルの select-statement の外部選択リストは、配列値であってはなりません。

文名

カーソルがオープンされたときに必ずカーソルの結果表を指定する準備済み select-statement を指定します。 statement-name は、ソース・プログラムの別の DECLARE CURSOR ステートメントで指定されたステートメント名と同じであってはなりません。準備されたSELECT文の説明については、 PREPARE文を参照してください。

カーソルを SENSITIVE DYNAMIC または SENSITIVE STATIC として定義する場合、準備済み select-statement に SQL データ変更ステートメントを含めないでください。

注釈 DECLARE CURSOR

オープン状態のカーソルは、結果表と、その表の行に対する相対位置を示します。表は、カーソルの SELECT ステートメントによって指定される結果表です。

読み取り専用カーソル:

結果表が読み取り専用の場合、カーソルは読み取り専用になります。 INSTEAD OF トリガーを使用してビューを参照するカーソルは、位置付け UPDATE ステートメントや位置付け DELETE ステートメントではこのカーソルを使用することができないため、読み取り専用となります。 カーソルの選択文について、以下のステートメントの1つ以上が真である場合、結果テーブルは読み取り専用となります

最初の FROM 文節に次のいずれかが指定されているか、または含まれている。
- 複数の表またはビュー
- 更新可能な列を持たないカタログ表
- 読み取り専用ビュー
- ネストされた表の式
- 表関数
- システム管理のマテリアライズ照会表
- システム期間テンポラル表であり、SYSTEM_TIME の期間指定が使用されている単一の表
- 直接または間接的にビュー定義の外部全選択の FROM 文節でシステム期間テンポラル表を参照し、SYSTEM_TIME の期間指定が使用されている単一の表
最初の SELECT 文節がキーワード DISTINCT を指定しているか、集約関数を含んでいるか、その両方を使用している。
SQL データ変更ステートメントが含まれている。
外部副選択が GROUP BY 文節、HAVING 文節、またはその両方の文節を含んでいる。
外部副選択の基本オブジェクトと副照会の基本オブジェクトが同じ表であるような副照会が含まれている。
次のいずれかの演算子または文節が指定されている。
- セット演算子
- ORDER BY 文節 (カーソルが SENSITIVE STATIC 両方向スクロールとして宣言されている場合を除く)
- FOR READ ONLY 文節
分離レベル UR で実行され、FOR UPDATE 文節が指定されていない。
これは VALUES 文節です。

結果表が読み取り専用でない場合には、結果表の基礎行の更新または削除にカーソルを使用することができます。

更新される列を参照する：

FETCH文を使用して、後で更新される列を取得する場合は、列を選択する際にFOR UPDATE OFを指定します。次に、その後の UPDATE または DELETE 文で WHERE CURRENT OF を指定します。これらの条項により、 Db2 が更新中の列のインデックス経由のアクセスを選択することができなくなり、そうでないと Db2 が同じ行を複数回読み込む可能性がある。

詳細は、「以前に取得したデータの更新」を参照してください。

実施される行アクセス制御または列アクセス制御の表:

カーソルの select-statement で、行アクセス制御または列アクセス制御が適用される表を参照できます。行アクセス制御または列アクセス制御は、カーソルが読み取り専用であり、カーソル・センシティビティーに影響を与えないかどうかの判別に影響しません。

静的両方向スクロール・カーソルに対する作業ファイル・データベースの要件:

静的両方向スクロール・カーソルを使用するには、まず最初に、このデータベース内に作業ファイル・データベースとページ・サイズが 32 KB の表スペースを少なくとも 1 つ作成する必要があります。その理由は、静的両方向スクロール・カーソルでは、カーソルがオープンされている間、結果表に対する一時表が必要だからです。 Db2 一時的な結果テーブルに使用するテーブルスペースを選択します。動的両方向スクロール・カーソルには、宣言済み一時表は必要ありません。

空文字列を含む静的スクロール可能なカーソルの宣言については、 Db2 は空文字列ごとに一時テーブル領域に1バイトを割り当てます。以下の例は、空ストリングがある両方向スクロール・カーソル宣言を示しています。

EXEC SQL DECLARE CSROWSTAT SENSITIVE STATIC SCROLL CURSOR
  WITH ROWSET POSITIONING WITH HOLD FOR
  SELECT ID1,'' 
  FROM TB;

COBOL および Fortran プログラム内のカーソル:

COBOL および Fortran のソース・プログラムにおいては、DECLARE CURSOR ステートメントが、名前を使ってカーソルを明示参照するすべてのステートメントより前になければなりません。その他のホスト言語の場合は、プリコンパイラーが 2 パス・オプションを提供しているので、この規則は、それらの言語には必ずしも適用されません。他のホスト言語でも、2 パス・オプションを使用していなければ、この規則が適用されます。

REXXにおけるカーソル：

REXXプロシージャ内のDECLARE CURSOR文でホスト変数を使用する場合は、DECLARE CURSOR文はPREPAREおよびEXECUTEの対象でなければなりません。

カーソルの有効範囲:

cursor-name の有効範囲は、これが定義されたソース・プログラム、すなわち、プリコンパイラーに実行依頼されたアプリケーション・プログラムです。したがって、カーソル宣言と一緒にプリコンパイルされたステートメントでしか、カーソルの参照はできません。例えば、あるプログラムから呼び出された別の COBOL プログラムが、呼び出し側プログラムによってオープンされたカーソルを使うことはできません。また、Fortran サブプログラムで定義されたカーソルは、そのサブプログラム内でしか参照できません。プロシージャー内で WITH RETURN を指定し、オープンされたままになっているカーソルが結果セットとして戻されます。

カーソルの有効範囲はそれが宣言されたプログラムですが、そのプログラムから作成された各パッケージ (またはプランの DBRM) にはカーソルの別個のインスタンスが含まれているので、プログラムの 1 回の実行において、カーソルの複数のインスタンスを使用することもできます。例えば、プログラムが CONNECT(2) オプションを指定してプリコンパイルされ、その DBRM を使用してロケーション X にパッケージを作成し、ロケーション Y にパッケージを作成するとします。このプログラムには、以下の SQL ステートメントが含まれています。

  DECLARE C CURSOR FOR ...
  CONNECT TO X
  OPEN C
  FETCH C INTO ...
  CONNECT TO Y
  OPEN C
  FETCH C INTO ...

2 番目の OPEN C ステートメントは、カーソル C の別個のインスタンスを参照しているので、エラーにはなりません。パッケージが異なるコレクション内にある場合、同じ概念が単一のロケーションにも適用されます。

SELECT ステートメントは、カーソルがオープンされる時点で評価されます。同じカーソルをオープンし、クローズした後、再度オープンした場合、結果は異なる可能性があります。カーソルの SELECT ステートメントに CURRENT DATE、 CURRENT TIME、または CURRENT TIMESTAMP が含まれている場合は、これらの特殊レジスターが参照されると、FETCH 操作ごとにそれぞれ同じ日時値が得られます。値はカーソルのオープン時に決定されます。同じ SELECT ステートメントを使用する複数のカーソルを並行してオープンできます。これらのカーソルはそれぞれ、独立したアクティビティーと見なされます。

データのブロック化:

データをより効率的に処理するために、 Db2 は読み取り専用カーソルに対してデータをブロックすることがあります。位置付け UPDATE ステートメント、または位置付け DELETE ステートメントにカーソルを使用しない場合は、カーソルを FOR READ ONLY と定義してください。

位置付け DELETE と分離レベル UR:

位置付け DELETE にカーソルを使用し、BIND オプションのために分離レベルが UR である場合は、FOR UPDATE を指定します。この場合、分離レベルは CS になります。

ストアード・プロシージャーからの結果セットの戻り:

ストアード・プロシージャー内で宣言されたカーソルは、次の条件がすべて満たされた場合に結果セットを戻します。

カーソルが WITH RETURN オプションを指定して宣言されている。分散環境では、カーソル・データの各結果セットのブロックは CALL ステートメントの応答で戻されます。
カーソルはストアード・プロシージャーから出た後オープンのままである。 SCROLL オプションを指定して宣言されたカーソルは、ストアード・プロシージャーを終了する前に、最初の行より前に位置付けられていなければなりません。
ストアード・プロシージャーが戻るときにコミットするように定義されている場合に、カーソルが WITH HOLD オプションを指定して宣言されている。

結果セットとは、カーソルがストアード・プロシージャーから出た後の現行位置の後のすべての行のセットです。結果セットは読み取り専用であると見なされます。同じプロシージャーが再呼び出しされると、指定した場所のストアード・プロシージャーに対するオープン状態の結果セット・カーソルは、自動的にデータベース管理システムによってクローズされます。

ユーザー定義関数を使って指定された両方向スクロール・カーソル

両方向スクロール・カーソルを使用して、行を複数回フェッチすることができます。このため、カーソルの選択リストに非 deterministic 関数を指定して両方向スクロール・カーソルを定義すると、行が複数回フェッチされ、フェッチごとに異なる結果が得られる可能性があります。 (ただし、両方向スクロール・カーソルの WHERE 文節での非 deterministic 関数の値は、カーソルがオープンされる際に取り込まれ、カーソルがクローズされるまで変更されません。) 同様に、外部アクションを伴うユーザー定義関数を指定して両方向スクロール・カーソルを定義すると、フェッチのたびにアクションが実行されます。

RETURN TO CLIENTで定義されたカーソルの複数のインスタンス：

ネイティブSQLプロシージャ内でカーソルが宣言されている場合、同じ名前のカーソルがすでにオープン状態であっても、WITH RETURN TO CLIENTとして宣言されたカーソルを開くことができます。この場合、既にオープンであったカーソルは結果セット・カーソルになり、そのカーソル名を使用してアクセスできなくなります。新規カーソルがオープンされ、そのカーソル名を使用してアクセスできるようになります。 CLOSE ステートメントが発行されると、カーソルの最後のインスタンスがクローズされます。新しいカーソルをクローズしても、以前に名前でアクセスできたカーソルは、再度カーソル名でアクセス可能にはなりません。このようにして結果セット・カーソルになるカーソルは、サーバーではアクセスできず、クライアントでのみ処理できます。

例 DECLARE CURSOR

以下の例のステートメントは、PL/I プログラムを前提としています。

例 1

C1 をクエリのカーソルとして宣言し、テーブル DSN8C10.DEPT からデータを取得します。照会自体が DECLARE CURSOR ステートメントに含まれています。

   EXEC SQL DECLARE C1 CURSOR FOR
      SELECT DEPTNO, DEPTNAME, MGRNO
      FROM DSN8C10.DEPT
      WHERE ADMRDEPT = 'A00';

例 2

C1 をクエリのカーソルとして宣言し、テーブル DSN8810.DEPT からデータを取得します。データは後で検索 UPDATE によって更新され、照会の実行時にはデータをロックする必要があるとします。照会自体が DECLARE CURSOR ステートメントに含まれています。

   EXEC SQL DECLARE C1 CURSOR FOR
      SELECT DEPTNO, DEPTNAME, MGRNO
      FROM DSN8C10.DEPT
      WHERE ADMRDEPT = 'A00'
      FOR READ ONLY WITH RS USE AND KEEP EXCLUSIVE LOCKS;

例 3

C2 を、 STMT2 という名前の文のカーソルとして宣言します。

   EXEC SQL DECLARE C2 CURSOR FOR STMT2;

例 4

C3® をテーブル DSN8C10.EMP の位置指定更新で使用されるクエリのカーソルとして宣言します。完了した更新は、カーソルをクローズすることなく、時々コミットできるようにします。

   EXEC SQL DECLARE C3 CURSOR WITH HOLD FOR
     SELECT * FROM DSN8C10.EMP
       FOR UPDATE OF WORKDEPT, PHONENO, JOB, EDLEVEL, SALARY;

どの列を更新すべきかを指定する代わりに、列の名前を指定せずに FOR UPDATE 文節を使用して、すべての更新可能な列を更新するように指示することができます。

例 5

ストアドプロシージャ SP1 内で、 C4 をテーブル DSN8C10.PROJ のクエリ用カーソルとして宣言します。リターン時にコミットを実行する、SP1 の呼び出し元に結果セットを戻すためにカーソルを使用できるようにします。

   EXEC SQL DECLARE C4 CURSOR WITH HOLD WITH RETURN FOR
      SELECT PROJNO, PROJNAME
      FROM DSN8C10.PROJ
      WHERE DEPTNO = 'A01';

例 6

次の例では、DECLARE CURSOR文でカーソル名 C5 をSELECTの結果に関連付け、カーソルがスクロール可能であることを指定しています。結果表は更新可能なので、C5 は、位置付け UPDATE および位置付け DELETE を行うことができます。

   EXEC SQL DECLARE C5 SENSITIVE STATIC SCROLL CURSOR FOR
      SELECT DEPTNO, DEPTNAME, MGRNO
      FROM DSN8C10.DEPT
      WHERE ADMRDEPT = 'A00';

例 7

次の例では、DECLARE CURSOR文でカーソル名 C6 をSELECTの結果に関連付け、カーソルがスクロール可能であることを指定しています。

   EXEC SQL DECLARE C6 INSENSITIVE SCROLL CURSOR FOR
      SELECT DEPTNO, DEPTNAME, MGRNO
      FROM DSN8C10.DEPT
      WHERE DEPTNO;

例 8

次の例は、アプリケーションプログラムが動的スクロール可能なカーソルをどのように使用するかを示しています。まず、テーブルを作成し、データを入力します。

   CREATE TABLE ORDER
         (ORDERNUM  INTEGER,
          CUSTNUM   INTEGER, 
          CUSTNAME  VARCHAR(20), 
          ORDERDATE CHAR(8), 
          ORDERAMT  DECIMAL(8,3),
          COMMENTS  VARCHAR(20));

約 500 行を挿入またはロードして、表にデータを追加します。

   EXEC SQL DECLARE CURSOR ORDERSCROLL
      SENSITIVE DYNAMIC SCROLL FOR
      SELECT ORDERNUM, CUSTNAME, ORDERAMT, ORDERDATE FROM ORDER 
      WHERE ORDERAMT > 1000
      FOR UPDATE OF COMMENTS;

両方向スクロール・カーソルをオープンします。

   OPEN CURSOR ORDERSCROLL;

両方向スクロール・カーソルから順方向にフェッチを行います。

   -- Loop-to-fill-screen
         -- do 10 times 
          FETCH FROM ORDERSCROLL INTO :HV1, :HV2, :HV3, :HV4;
         -- end

両方向スクロール・カーソルから RELATIVE フェッチを行います。

   -- Skip-forward-100-rows
         FETCH RELATIVE +100 
          FROM ORDERSCROLL INTO :HV1, :HV2, :HV3, :HV4;

   -- Skip-backward-50-rows
         FETCH RELATIVE -50 
          FROM ORDERSCROLL INTO :HV1, :HV2, :HV3, :HV4;

両方向スクロール・カーソルから ABSOLUTE フェッチを行います。

   -- Re-read-the-third-row
         FETCH ABSOLUTE +3 
          FROM ORDERSCROLL INTO :HV1, :HV2, :HV3, :HV4;

両方向スクロール・カーソルから RELATIVE フェッチを行います。

   -- Read-the-third-row-from current position
         FETCH SENSITIVE RELATIVE +3 
          FROM ORDERSCROLL INTO :HV1, :HV2, :HV3, :HV4;

両方向スクロール・カーソルによって位置付け UPDATE を実行します。

   -- Update-the-current-row
         UPDATE ORDER SET COMMENTS = "Expedite" 
          WHERE CURRENT OF ORDERSCROLL;

両方向スクロール・カーソルをクローズします。

   CLOSE CURSOR ORDERSCROLL;

例 9

C1 をクエリのカーソルとして宣言し、テーブル DEPT から行セットを取得します。準備済みステートメントは MYCURSOR です。

   EXEC SQL DECLARE C1 CURSOR 
      WITH ROWSET POSITIONING FOR MYCURSOR;