カーソル感知性の例：削除されたロー

この例では、簡単なクエリを使って、異なるカーソルが、削除中の結果セットのローに対してどのように応答するかを見ていきます。

次の一連のイベントを考えてみます。

アプリケーションが、次のようなサンプルデータベースに対するクエリについてカーソルを開く。

SELECT EmployeeID, Surname
FROM Employees
ORDER BY EmployeeID;

この場合、カーソルアクションの結果は、カーソルの感知性によって異なります。

insensitive カーソル DELETE は、カーソルを使用して表示される結果セットのメンバーシップにも値にも反映されません。

sensitive カーソル 結果セットのメンバーシップが変更されたため、ロー (105) は結果セットの最初のローになります。

動作	結果
前のローをフェッチする	「`ローが見つかりません。`」というエラーを返す。前のローが存在しない。
最初のローをフェッチする (絶対フェッチ)	ロー 105 を返す
2 番目のローをフェッチする (絶対フェッチ)	ロー 160 を返す

value-sensitive カーソル 結果セットのメンバーシップは固定であり、ロー 105 は、結果セットの 2 番目のローのままです。DELETE はカーソルの値に反映され、結果セットに有効なホールを作成します。

動作	結果
前のローをフェッチする	「`カーソルの現在のローがありません。`」というエラーを返す。最初のローが以前存在したカーソルにホールがある。
最初のローをフェッチする (絶対フェッチ)	「`カーソルの現在のローがありません。`」というエラーを返す。最初のローが以前存在したカーソルにホールがある。
2 番目のローをフェッチする (絶対フェッチ)	ロー 105 を返す

asensitive カーソル 変更に対して、結果セットのメンバーシップおよび値は確定されません。前のロー、最初のロー、または 2 番目のローのフェッチに対する応答は、特定のクエリ最適化方法によって異なります。また、その方法にワークテーブル構成が含まれているかどうか、フェッチ中のローがクライアントからプリフェッチされたものかどうかによっても異なります。
多くのアプリケーションで感知性の重要度は高くはなく、その場合、asensitive カーソルは利点をもたらします。特に、前方専用や読み取り専用のカーソルを使用している場合は、基本となる変更は表示されません。また、高い独立性レベルで実行している場合は、基本となる変更は禁止されます。