Standard または Advancedのライセンスで利用可能。
ジオデータベース レプリケーションでは、エンタープライズ ジオデータベースでホストされているレプリカに対する同期プロセスでバージョニングが使用されます。 ただし、一方向レプリケーションで履歴管理を使用して変更を追跡している場合は例外です。
バージョニングによって、送信する変更内容と受信する変更内容が決定されます。 ここでは、次の各同期プロセスでバージョニングがどのように使用されるかを説明します。
変更の送信
レプリカから変更が送信されると、レプリカ バージョン (レプリカの作成時に定義される) とシステム バージョンが解析されます。 この解析により、以前の同期時にすでに送信されている編集内容を除外したり、再送が必要な変更を判断したりすることができます。 ファイル ジオデータベースまたはパーソナル ジオデータベース内のチェックアウト レプリカの場合は、すべての編集内容が含まれている内部テーブルが解析されます。 履歴管理を使用している一方向レプリケーションの場合は、アーカイブ クラスを解析することにより、送信する変更内容を決定します。
変更の受信
レプリカによる変更の受信は、以下の手順で行われます。
まず、変更が同期バージョンに適用されます。 同期バージョンは、レプリカ バージョンの子です。 レプリカ バージョンへのリコンサイルとポストが終了するまで同期済みの変更を一時的に保持するように設計されています。 双方向レプリカと一方向レプリカの場合は、同期の実行時までバージョンが作成されませんが、チェックアウト レプリカの場合は、レプリカの作成時にバージョンが作成されます。 下の図にあるレプリカ バージョンには、デフォルト バージョンと名前付きバージョンをどちらも使用することができます。
次に、同期バージョンがレプリカ バージョンに対してリコンサイルされます。 この段階での動作は、レプリカの種類によって異なります。
- 双方向レプリカ - 双方向レプリカの場合は、リコンサイル時に競合が発生する可能性があります。 競合が検出された場合は、リコンサイル ポリシーによって、競合の処理方法が決定されます。 同期の際に、自動リコンサイル ポリシーか手動リコンサイル ポリシーのどちらかを選択できます。 競合が存在しないか自動リコンサイル ポリシーによって自動的に競合した場合、レプリカ バージョンに対して同期バージョンがポストされます。
- チェックアウト レプリカ - チェックアウト レプリカの場合、リコンサイルとポストはオプションの処理であり、デフォルトでは実行されません。 リコンサイルとポストを実行しない場合、変更は同期バージョンに残ります。 後からリコンサイルとポストを手動で実行することができます。 リコンサイルとポストを手動で実行する場合の手順は、双方向レプリカの場合と同じです。
- 一方向レプリカ - 一方向レプリカでは、レプリカ バージョンの変更が常に上書きされるので、未解決の競合は存在しません。 シンプル モデル タイプを使用している場合は、子レプリカ内のデータをバージョン対応登録する必要がありません。 子レプリカがバージョン対応登録されていない場合は、変更がベース テーブルに直接適用されます。 また、子レプリカがファイル ジオデータベースでホストされている場合は、変更が直接上書きされます。
変更がレプリカ バージョンにポストされると、同期バージョンが削除されます。 手動リコンサイル ポリシーを選択しており、競合が発生している場合は、自分でリコンサイルとポストを後から実行するかどうかは、自分自身で判断できます。 双方向レプリカの場合は、同期バージョンが存在する限り、レプリカは競合状態と見なされます。 レプリカが競合状態の場合、そのレプリカは変更を受信することは可能ですが、変更を送信することはできません。
