La replicación de geodatabase utiliza el versionado durante la sincronización para las réplicas alojadas en geodatabases corporativas. Se utiliza el versionado para determinar los cambios que se van a enviar y recibir. La excepción es cuando se está utilizando el archivado para realizar el seguimiento de cambios en una replicación unidireccional.
A continuación, se describe cómo se utiliza el versionado en cada uno de estos procesos de sincronización:
Enviar cambios
Cuando una réplica envía cambios, se analizan la versión de réplica (definida durante la creación de la réplica) y las versiones del sistema. Este análisis puede excluir ediciones que ya se han enviado durante sincronizaciones anteriores o determinar que algunos cambios deben enviarse de nuevo. Para las réplicas de réplica de check-out/check-in en geodatabases de archivos, se analiza una tabla interna que contiene todas las ediciones. Para la replicación unidireccional utilizando archivado, se analiza la clase de archivado para determinar qué cambios enviar.
Recibir cambios
Cuando una réplica recibe cambios, ocurre lo siguiente:
Primero, se aplican los cambios a la versión de sincronización. La versión de sincronización es un elemento secundario de la versión de réplica, diseñada para alojar temporalmente cambios sincronizados hasta que se concilien y publiquen en la versión de réplica. Para las réplicas bidireccionales y unidireccionales, es posible que la versión no se cree hasta el momento de la sincronización, mientras que, para las réplicas de check-out/check-in, la versión se crea en el momento de la creación de la réplica. En los diagramas siguientes, la versión de réplica podría ser la predeterminada o una con nombre.
A continuación, la versión de sincronización se concilia con la versión de réplica. El comportamiento en este paso depende del tipo de réplica:
- Réplicas bidireccionales: para las réplicas bidireccionales, puede haber conflictos durante la conciliación. Si se detectan conflictos, se utiliza una política de conciliación para determinar cómo gestionarlos. Si no hay ningún conflicto, o una política de conciliación automática resuelve los conflictos, la versión de réplica se envía con la versión de sincronización.
- Réplicas de check-out/check-in: para las réplicas de check-out/check-in, la conciliación y la publicación son opcionales y no se ejecutan de manera predeterminada. Si prefiere no conciliar ni publicar, los cambios se mantendrán en la versión de sincronización. Entonces puede conciliar y enviar manualmente en un momento posterior. Si decide conciliar y enviar, el comportamiento es el mismo que con las réplicas bidireccionales.
- Réplicas unidireccionales: con las réplicas unidireccionales, los cambios en la versión de réplica siempre se sobrescriben y no se crean conflictos. Cuando se utiliza un tipo de modelo sencillo, no es necesario que los datos de la réplica secundaria estén versionados. Si la réplica secundaria no se versiona, se aplican los cambios directamente en las tablas base. Además, los cambios se sobrescriben directamente si la réplica secundaria se aloja en una geodatabase de archivos.
Una vez los cambios se han publicado en la versión de réplica, la versión de sincronización se elimina. Para las réplicas bidireccionales, siempre que exista la versión de sincronización, la réplica se considera en conflicto. Mientras esté en conflicto, se puede recibir cambios, pero no enviarlos desde la réplica.
Nota:
Es recomendable realizar la conciliación y la publicación con la sesión iniciada como el propietario de la réplica. De forma predeterminada, la versión de sincronización es privada y solo permite el acceso al propietario de la réplica. Si hace esta versión pública, puede conciliar y guardar los cambios como un usuario distinto del propietario de la réplica. Sin embargo, debe publicar los cambios con la sesión iniciada como propietario de la versión de réplica.