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