クライアント データセットを利用した更新のキャッシュ
デフォルトでは、大抵のデータセットにおいてデータ編集する際に、レコードを削除または登録するたびに、データセットは、トランザクションを生成、そのレコードをデータベース サーバーに対して削除または書き込み、そしてトランザクションをコミットします。データベースへの変更書き込みに何らかの問題がある場合、アプリケーションは即座に通知を受けます。つまり、データセットがレコードを投稿する際に例外を発生させます。
データセットがリモート データベース サーバーを使用する場合、カレント レコードを編集した後、新たなレコードに移動するたびに、アプリケーションとサーバー間でネットワーク トラフィックが発生するため、この方法ではパフォーマンスが低下する可能性があります。ネットワーク トラフィックを最小限にするためには、更新をローカルでキャッシュするとよいでしょう。更新をキャッシュする際、アプリケーションはデータベースからデータを取得し、それをローカルでキャッシュそして編集し、その後、キャッシュされた更新内容を、1 回のトランザクションでデータベースに適用します。更新をキャッシュする際、データセットへの変更(変更の投稿やレコードの削除など)は、データセットの基となるテーブルに直接書き込みに行く代わりに、ローカルに保存されます。変更が完了したら、アプリケーションはキャッシュされた変更をデータベースに書き込むメソッドを呼び出し、その後キャッシュをクリアします。
更新のキャッシュは、トランザクション時間を最小化し、ネットワーク トラフィックを削減します。しかしながら、キャッシュされたデータはアプリケーションのローカルにあるため、トランザクション制御下にはありません。これは、ローカルのつまりメモリ内のデータのコピーに対して作業している間に、他のアプリケーションが基のデータベース テーブルにあるデータをキャッシュする可能があることを意味します。また、キャッシュした更新を適用するまでは、他のアプリケーションがその変更を見ることもできません。このため、キャッシュされた更新は、変更されやすいデータで作業するアプリケーションには、適してない場合があります。データベースに変更をマージしようとする際に、競合を数多く発生させたり、または遭遇してしまうからです。
BDE や ADO では更新キャッシュに代わるメカニズムを提供していますが、更新キャッシュのクライアント データセットには、いくつもの利点があります:
- データセットがマスタ/詳細関係にリンクされている際、更新の適用は代わりに処理してくれます。これにより、複数のリンクづけされたデータセットが、正しい順番で適用されます。
- クライアント データセットは、更新プロセスに対して最大限の制御を提供してくれます。レコードの更新のために生成された SQL に影響を与えるプロパティを設定したり、複数テーブル結合からレコードを更新する際に使用するテーブルを指定することができるほか、BeforeUpdateRecord イベント ハンドラから手動で更新を適用することも可能です。
- キャッシュされた更新をデータベース サーバーに適用するときにエラーが発生した場合、クライアント データセット(およびデータセット プロバイダ)のみが、データセットからの元の(編集前の)値と、失敗した更新の新しい(編集後の)値に加え、データベース サーバー上のカレント レコード値についての情報を提供することができます。
- クライアント データセットにより、全更新がロールバックされる前に、許容できる更新エラーの数を指定することができます。
以下のトピックでは、クライアント データセットを使って更新情報をキャッシュする方法をさらに詳しく説明しています。