スクロール可能なカーソル

  • [アーティクル]

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

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

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

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

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

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

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