RDA の競合の検出と報告
Microsoft SQL Server 2005 Compact Edition (SQL Server Compact Edition) でリモート データ アクセス (RDA) を使用する場合は、SQL Server を実行中のコンピュータでプッシュ操作中に更新できない行に対し、制限付きの競合報告メカニズムが提供されます。
.gif) 重要 : |
|---|
| RDA における行の競合とは、SQL Server Compact Edition から SQL Server テーブルにプッシュしたとき、エラーが原因で正常に実行できなかった挿入操作、更新操作、または削除操作であることが厳密に定義されています。複数のユーザーによるデータの変更は、その結果がエラーとならない限り、競合と見なされません。 |
レプリケーションで提供されるような特定の競合回避モジュールが RDA で提供されることはありませんが、SQL Server Compact Edition では競合するすべての行がエラー テーブルに記録されます。エラー テーブルは、Pull メソッドの引数として指定できます。このエラー テーブルには、push 中に発生したすべてのエラーが記録されます。エラー テーブルを使用すると、競合の検出と報告を管理するアプリケーションを開発できます。
サーバーにプッシュされた SQL Server Compact Edition データベースに対する変更は、変更が受理された順序で適用されます。SQL Server テーブルの更新では、最後のユーザーが行った変更が反映されます。
RDA では、SQL Server Compact Edition から SQL Server に行をプッシュできない場合に競合が発生します。RDA では、行レベルの監視のみがサポートされます。したがって、成功する行もあれば失敗する行もあります。これは、Push メソッドで選択しているオプションによって決まります。RDA での競合を監視するには、Pull メソッドに TRACKINGON または TRACKINGON_INDEXES を指定します。
RDA が監視されているテーブルを使用する際、テーブルを正しくフィルタ選択して、データの伝達時に安定したネットワーク接続を使用することで、競合とエラーを回避できます。
RDA での競合の発生
行への変更は、次の理由により、サーバーで適用されません。
- RDA は、特にデバイスの監視されているテーブルで変更された各行に対する挿入操作、更新操作、および削除操作を監視します。したがって、同一テーブルに、サーバーで挿入された行と同じ主キーを持つ行がクライアントで挿入されると、既に挿入済みの行なので、クライアントからのプッシュがエラーで失敗します。
- 各ユーザーのデータが正しくパーティション分割されていない場合、あるユーザーが同じ行を更新しようとしたときに、別のユーザーが行を削除できます。
- また、以前のプッシュが中断された際のエラーにより、サーバーへの行のプッシュが失敗することもあります。たとえば、ユーザーがサーバーにデータをプッシュし始めて、その中に挿入操作が含まれている場合、プッシュ中にネットワーク接続が切断されます。クライアントにより、プッシュがネットワーク接続損失のために失敗したというメッセージが表示されます。ただし、実際には、変更はサーバーで適用されました。クライアントでネットワーク接続が回復してから、ユーザーが同じデータの 2 回目のプッシュを試みても、以前のプッシュ処理中に挿入された行は適用されません。この場合、アプリケーションでは、2 回目のプッシュに基づいた主キー重複によるエラーがあったエラー テーブルのすべてのエラーを無視する必要があります。
エラー テーブル
RDA は、失敗した行と一緒に SQL Server Compact Edition データベースのエラー テーブルにエラーを格納することによって、データの競合、つまりエラーによりサーバーに適用されなかった行を監視します。このテーブルは、Pull メソッドで定義します。その後、push 命令中にエラーが発生すると、すべてのエラーがエラー テーブルに格納されます。
Push メソッドを使用するときに、主キーの重複などのエラーにより行がサーバーに適用されない場合は、Pull メソッドで最初に定義したエラー テーブル名を参照して行を解決します。Pull メソッドの ErrorTableName プロパティには、プッシュ エラーの格納先テーブルの名前を指定します。このエラー テーブルはすぐに作成されますが、最初の時点で行は含まれません。ErrorTableName を指定できるのは、Pull メソッドで TRACKINGON または TRACKINGON_INDEXES を指定した場合だけです。
Push メソッドの処理中に行を適用できないことが原因でエラーが発生すると、SQL Server Compact Edition ではエラーごとにレコードがテーブルに挿入されます。ベース テーブルのすべての列に加えて、エラーが発生した理由と時期を識別するために、3 つの列が追加されます。s_ErrorDate 列には、エラーが発生した日付と時刻が返されます。s_OLEDBErrorNumber 列には、サーバーに行を適用するときに発生したエラーの HResult が返されます。s_OLEDBErrorString 列には、エラーの説明が含まれます。Push メソッドが完了し、そのメソッドによりサーバーへの行の適用が試行されたときにエラーが発生した場合、警告 (SSCE_WRN_RDAERRORROWSRETURNED、値 28800) がアプリケーションに報告されるので、アプリケーションがエラー テーブルを調査し、エラーの原因を特定できます。
エラー テーブルの管理
関連付けられた RDA 監視対象テーブルが削除されると、エラー テーブルに行が存在する場合でも、エラー テーブルが自動的に削除されます。エラー テーブルにある行はサーバーで適用されないので、開発者は、競合していると考えられる行を解決する必要があります。
最初にデータをサーバーにプッシュしているときに発生したエラーを正しく解決するには、デバイスのデータを更新することが必要になる場合があります。監視されているテーブルを削除したときに、エラー テーブルのデータを失わないように、エラー テーブルのデータをキャッシュすることをお勧めします。または、元の監視されているテーブルとは別の名前のテーブルに、更新されたデータをプルできます。
データ プッシュ後に発生したエラーの解決
失敗した行と共にエラー テーブルに格納されるエラーでは、サーバーでデータを挿入、更新、または削除できなかった理由が説明されます。エラーによって異なりますが、サーバーでのデータの現在の状態を把握しておくことが非常に重要です。監視対象のテーブルを削除するとエラー テーブルも削除されるので、アプリケーションをビルドする際に、この状況に対応できるようにする必要があります。
エラーと非バッチ トランザクション
非バッチ トランザクション (Push メソッドを使用する場合は BATCHINGOFF オプション) の処理中、競合が行レベルで検出されます。競合する行は、アプリケーションに戻され、指定されたエラー テーブルに格納されます。たとえば、アプリケーションで SQL Server に無効な行をプッシュしようとした場合、その行はアプリケーションに戻され、競合を示すエラー メッセージと共にエラー テーブルに格納されます。
競合する行がエラー テーブルに返されると、その行は元のテーブルから削除されます。テーブルは元の状態とは違う状態になっているので、発生した競合を解決するのがより困難になります。ユーザーが競合するデータを修正できるように、アプリケーションを設計する必要があります。必要であれば、サーバーからテーブルをもう一度プルして、状況を正しく解決してください。
デバイス上のテーブルを削除すると、エラー テーブルが削除されます。一時的な場所にエラー テーブルの行をキャッシュするか、またはサーバーから別のテーブルにデータをプルする必要があります。問題のある行は SQL Server Compact Edition データベースのテーブルから移動されているため、テーブルをもう一度更新して正しいサーバー データを反映することが重要です。エラーのある行が最初に更新された場合、その行が後続のプッシュで成功するように、同じ行への更新が必要になります。行を更新済みの場合でも、サーバーの行が削除された場合は、その行をテーブルに追加し直して、挿入が成功するようにもう一度プッシュする必要があります。
エラーとバッチ トランザクション
RDA では、すべての行でのプッシュ処理を完全に成功させることが必要な、バッチ プッシュ (Push メソッドを使用する場合は BATCHINGON オプション) もサポートされています。1 行でも失敗すると、プッシュ トランザクション全体が失敗し、データの更新は一切行われません。競合する行は、エラー テーブルにコピーされます。このオプションは、多少は簡単なメカニズムで競合を解決できるので、優先オプションとなります。非バッチ プッシュの場合と異なり、元の Microsoft Windows CE データベースは影響を受けません。アプリケーションを設計する際に、ユーザーが競合するデータを修正でき、修正後のデータを元の Windows CE ベースのデータベースにマージできるしくみを実装するようにしてください。元の行がそのまま残るので、エラーによって異なりますが、サーバー データをすぐにプルし直す必要なく、行の正しい解決を特定できる場合があります。たとえば、行が整合性違反により失敗すると、デバイスの行が更新され、Push メソッドがサーバーにデータをプッシュするために呼び出されます。エラー テーブルは、競合する行のコピー前に自動的にクリーニングされるので、このオプションにはクリーナ管理機能も用意されています。テーブルに存在するのは、前回のプッシュ操作からの競合のみです。