次の方法で共有


スクロール可能カーソル

最新の画面ベースのアプリケーションでは、ユーザーはデータを前後にスクロールします。 このようなアプリケーションでは、以前にフェッチされた行に戻すのが問題です。 1 つの可能性は、カーソルを閉じて再度開き、カーソルが必要な行に到達するまで行を取得することです。 もう 1 つの可能性は、結果セットを読み取り、ローカルにキャッシュし、アプリケーションでスクロールを実装することです。 どちらの可能性も小さな結果セットでのみ適切に機能し、後者の可能性は実装が困難です。 より良い解決策は、結果セット内で前後に移動できる スクロール可能なカーソル を使用することです。

スクロール可能なカーソルは、ユーザーがデータを前後にスクロールする最新の画面ベースのアプリケーションでよく使用されます。 ただし、スクロール可能カーソルは、一般に順方向専用カーソルよりもコストが高いので、アプリケーションでは順方向専用カーソルがジョブを実行しない場合にのみ、スクロール可能なカーソルを使用する必要があります。

後方に移動する機能では、前方専用カーソルには適用できないという疑問が発生します。スクロール可能なカーソルは、以前にフェッチされた行に加えられた変更を検出する必要がありますか? つまり、更新、削除、新しく挿入された行を検出する必要がありますか?

この質問は、結果セット (特定の条件に一致する行のセット) の定義では、行がその条件に一致するかどうかを確認する際に状態が示されず、行がフェッチされるたびに同じデータを含める必要があるかどうかも示されないために発生します。 前者の省略により、スクロール可能なカーソルは行が挿入されたか削除されたかを検出でき、後者では更新されたデータを検出できます。

変更を検出する機能は役に立つことがあり、そうでない場合もあります。 たとえば、会計アプリケーションでは、すべての変更を無視するカーソルが必要です。カーソルに最新の変更が表示されている場合、帳簿を正確に調整することは不可能です。 一方、航空会社の予約システムには、データに対する最新の変更を示すカーソルが必要です。このカーソルがない場合は、データベースを絶えず再クエリして、最新のフライトの可用性を表示する必要があります。

さまざまなアプリケーションのニーズに対応するために、ODBC では 4 種類のスクロール可能なカーソルが定義されています。 これらのカーソルは、経費と結果セットの変更を検出する機能の両方で異なります。 スクロール可能なカーソルが行の変更を検出できる場合、それらの行の再フェッチを試みるときにのみ検出できることに注意してください。現在フェッチされている行に対する変更をデータ ソースがカーソルに通知する方法はありません。 変更の可視性もトランザクション分離レベルによって制御されることに注意してください。詳細については、「トランザクションの 分離」を参照してください。

このセクションでは、次のトピックを扱います。