クライアントからサーバーへのデータのプッシュ
クライアントからサーバーにデータをプッシュする作業では、Microsoft SQL Server Compact 3.5 の変更が SQL Server テーブルに反映されます。詳細については、「Push メソッド」を参照してください。
アプリケーションでは、監視オプションがオンに設定された状態で Pull メソッドを呼び出し、ローカルの SQL Server Compact 3.5 テーブルを作成しておく必要があります。
リモート データ アクセス (RDA) により監視される Pull メソッドと Push メソッドでは、オプティミスティック同時実行制御が使用されます。SQL Server では、プルされたレコードのロックは保持されません。アプリケーションで Push が呼び出されると、ローカルの SQL Server Compact 3.5 データベースに加えられた変更内容が SQL Server データベースに無条件に適用されます。このため、他のユーザーによって SQL Server データベースに加えられた変更内容は失われることがあります。
バッチ
RDA_BATCHOPTION では、SQL Server テーブルに送信する変更を SQL Server Compact 3.5 でバッチ処理するかどうかを指定します。既定の設定は BATCHINGOFF です。この場合、変更内容 (挿入、更新、および削除された内容) は、個別のトランザクションとして SQL Server のテーブルに適用されます。トランザクションが成功するかどうかは、他のトランザクションとは無関係です。BATCHINGON では、すべての変更が 1 回のトランザクションとして送信されます。この場合、トランザクションが成功するには、すべての変更内容の転送が成功する必要があります。1 つの変更でも転送に失敗すると、トランザクション全体が失敗し、変更内容は SQL Server テーブルに一切反映されません。BATCHINGON は既定のオプションではありませんが、開発者によっては、競合を解決するコードを作成する際に、より簡単なメカニズムとしてこのオプションを使用できる場合があります。詳細については、「RDA の競合の検出と報告」を参照してください。
BATCHINGON および BATCHINGOFF のいずれの場合も、発生したエラーの情報はすべてエラー テーブルに記録されます。最初に発生したエラーのみが記録されるということはありません。たとえば、BATCHINGON を指定した場合、変更された 5 行のうち 3 行が失敗すると、変更内容はまったく転送されませんが、発生した 3 つのエラーがエラー テーブルに記録されます。BATCHINGOFF を指定した場合は、同じ 3 つのエラーがエラー テーブルに記録されますが、成功した 2 行については正常に SQL Server のテーブルに反映されます。
非バッチ トランザクション
非バッチ トランザクション (BATCHINGOFF オプション) の場合、競合の検出は行レベルで処理されます。競合する行は、アプリケーションに戻され、指定されたエラー テーブルに格納されます。たとえば、アプリケーションで SQL Server に無効な行をプッシュしようとした場合、その行はアプリケーションに戻され、競合を示すエラー メッセージと共にエラー テーブルに格納されます。
競合する行が戻され、エラー テーブルに格納された場合、その行はデバイスの元のデータベースから削除されます。競合するデータをユーザーが修正でき、修正後のデータを元の Windows Mobile ベースのデータベースにマージできるしくみをアプリケーション側に実装するようにしてください。
バッチ トランザクション
RDA ではバッチ プッシュ (BATCHINGON オプション) もサポートされています。この場合、すべての行のプッシュが成功しないとプッシュ処理全体は成功しません。1 行でも失敗すると、プッシュのトランザクション全体が失敗し、データの更新は一切行われません。競合する行は、エラー テーブルにコピーされます。非バッチ プッシュの場合と異なり、元の Windows Mobile ベースのデータベースの整合性は維持されます。競合するデータをユーザーが修正でき、修正後のデータを元の Windows Mobile データベースにマージできるしくみをアプリケーション側に実装するようにしてください。エラー テーブルの内容は、競合する行がコピーされる前に自動的に削除されます。したがって、エラー テーブルには常に、直前のプッシュ操作での競合情報だけが格納されます。