この例では、簡単なクエリを使って、順序が変更されるように現在更新されている結果セット内のローに対して、カーソルがどのように応答するかを見ていきます。
次の一連のイベントを考えてみます。
アプリケーションが、次のようなサンプルデータベースに対するクエリについてカーソルを開く。
SELECT EmployeeID, Surname FROM Employees; |
EmployeeID | Surname |
---|---|
102 | Whitney |
105 | Cobb |
160 | Breault |
... | ... |
アプリケーションがカーソルを使って最初のローをフェッチする (102)。
アプリケーションがカーソルを使ってその次のローをフェッチする (105)。
別のトランザクションが employee 102 (Whitney) の従業員 ID を 165 に更新して変更をコミットする。
この場合、カーソルアクションの結果は、カーソルの感知性によって異なります。
insensitive カーソル UPDATE は、カーソルを使用して表示される結果セットのメンバーシップと値のどちらにも反映されません。
動作 | 結果 |
---|---|
前のローをフェッチする | ローのオリジナルコピーを返す (102) |
最初のローをフェッチする (絶対フェッチ) | ローのオリジナルコピーを返す (102) |
2 番目のローをフェッチする (絶対フェッチ) | 未変更のローを返す (105) |
sensitive カーソル 結果セットのメンバーシップが変更されたため、ロー (105) は結果セットの最初のローになります。
動作 | 結果 |
---|---|
前のローをフェッチする | SQLCODE 100 を返す。結果セットのメンバーシップは変更されたため、105 が最初のローになる。カーソルが最初のローの前の位置に移動する。 |
最初のローをフェッチする (絶対フェッチ) | ロー 105 を返す |
2 番目のローをフェッチする (絶対フェッチ) | ロー 160 を返す |
また、sensitive カーソルでフェッチすると、ローが前回読み取られてから変更されている場合、SQLE_ROW_UPDATED_WARNING 警告が返されます。警告が出されるのは 1 回だけです。同じローを再びフェッチしても警告は発生しません。
同様に、前回フェッチした後で、カーソルを使ってローを更新したり削除した場合には、SQLE_ROW_UPDATED_SINCE_READ エラーが返されます。sensitive カーソルで更新や削除を行うには、修正されたローをアプリケーションでもう一度フェッチします。
カーソルによってカラムが参照されなくても、任意のカラムを更新すると警告やエラーの原因となります。たとえば、Surname を返すクエリにあるカーソルは、Salary カラムだけが修正されていても、更新をレポートします。
value-sensitive カーソル 結果セットのメンバーシップは固定であり、ロー 105 は、結果セットの 2 番目のローのままです。UPDATE はカーソルの値に反映され、結果セットに有効な「ホール」を作成します。
動作 | 結果 |
---|---|
前のローをフェッチする | SQLCODE 100 を返す。結果セットのメンバーシップは変更されたため、105 が最初のローになる。カーソルはホール上、つまりロー 105 の前にある。 |
最初のローをフェッチする (絶対フェッチ) | SQLCODE -197 を返す。結果セットのメンバーシップは変更されたため、105 が最初のローになる。カーソルはホール上、つまりロー 105 の前にある。 |
2 番目のローをフェッチする (絶対フェッチ) | ロー 105 を返す |
asensitive カーソル 変更に対して、結果セットのメンバーシップおよび値は確定されません。前のロー、最初のロー、または 2 番目のローのフェッチに対する応答は、特定のクエリ最適化方法によって異なります。また、その方法にワークテーブル構成が含まれているかどうか、フェッチ中のローがクライアントからプリフェッチされたものかどうかによっても異なります。
更新警告とエラーの状態はバルクオペレーションモード (-b データベースサーバーオプション) では発生しません。
![]() |
DocCommentXchange で意見交換できます
|
Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1 |