Disponible con una licencia Standard o Advanced.
La replicación de geodatabases se genera encima del versionado. Durante la creación de réplicas, las versiones de las geodatabases de origen y destino se establecen como versiones de réplica. Los cambios en estas versiones de réplica se intercambian durante la sincronización. Puesto que las versiones de réplica están vinculadas, puede pensar en ellas como una manera de extender la jerarquía de versiones para que abarque varias geodatabases.
La versión predeterminada, o cualquier versión con nombre, se puede utilizar como versión de réplica para la réplica primaria o secundaria. Varias réplicas pueden compartir también la misma versión de réplica. Consulte Crear una réplica de check-out para aprender a establecer la versión de réplica en la versión principal o secundaria.
El siguiente diagrama muestra las versiones de réplica para réplicas unidireccionales y bidireccionales. Para la replicación bidireccional, la réplica primaria utiliza la versión denominada RV1 como versión de réplica. La réplica primaria de los ejemplos de replicación unidireccional utiliza la versión denominada RV2 como versión de réplica para ambos ejemplos.
Para ambas réplicas secundarias alojadas en geodatabases corporativas, la versión predeterminada es la versión de réplica. Aparte del hecho de que se utilizan para la replicación, las versiones de réplica no son diferentes de otras versiones como la V1 y la V2 que se muestran a continuación. Dado que los tipos de geodatabase personal y de archivos no admiten el versionado, no se crea ninguna versión de réplica en la geodatabase secundaria de la segunda réplica unidireccional, que se muestra a la derecha.
La replicación de check-out/check-in es capaz de replicar tanto datos versionados como datos no versionados y la réplica secundaria se puede alojar en una geodatabase corporativa, personal o de archivos.
Cuando una réplica secundaria se aloja en una geodatabase corporativa, se crea una nueva versión nominal para facilitar la edición y servir como versión de réplica en la réplica secundaria. El nombre de la versión de réplica secundaria se establece para que sea el mismo que el nombre de la réplica. Para editar los datos de la réplica secundaria, conéctese a la geodatabase corporativa y utilice el cuadro de diálogo Cambiar versiones para cambiar la versión a la versión de réplica secundaria. Una vez conectado a la versión de réplica secundaria, puede iniciar una sesión de edición. Las ediciones se deben realizar en la versión de réplica secundaria para volver a sincronizar las ediciones con la réplica principal.
La replicación de check-out/check-in también permite que las geodatabases personales o de archivos alojen réplicas secundarias. Puesto que estos tipos de geodatabase no admiten el control de versiones, no se crea ninguna versión de réplica para el elemento secundario. Éste es también el caso cuando se desprotegen datos no versionados. Para estos escenarios, se utiliza lógica adicional para determinar los cambios que se envían durante la sincronización.
El siguiente diagrama muestra dos ejemplos de réplicas de check-out y sus versiones de réplica. Una réplica primaria utiliza la versión RV1 como la versión de réplica, que la otra utiliza la versión RV2 como la versión de réplica. Una réplica secundaria está alojada en una geodatabase corporativa de archivos (también podría ser una geodatabase personal) y la otra está alojada en una geodatabase corporativa. Para la geodatabase corporativa que aloja la réplica secundaria, se creó automáticamente RV2 y se estableció como la versión de réplica durante la creación. El nombre RV2 para esta versión de réplica se tomó del nombre de la versión de réplica de la versión principal utilizada para crearla.
Utilizar el archivado para rastrear los cambios de la réplica
En el caso de la replicación unidireccional, puede utilizar el archivado en lugar del versionado para rastrear los cambios de la réplica. En el caso de esta opción, la geodatabase principal debe ser una geodatabase corporativa que haga referencia a la versión predeterminada. La ventaja de administrar la replicación de esta manera es que mantiene los procesos de conciliación, publicación y compresión separados del proceso de sincronización.
Cuando se utiliza el control de versiones para realizar el seguimiento de los cambios, se crean versiones del sistema. Debido a estas versiones del sistema, es necesario sincronizar periódicamente para lograr una compresión efectiva. Cuando se utiliza el archivado para hacer el seguimiento de los cambios de réplica, no se crean versiones del sistema. Por tanto, los procesos de conciliación, publicación y compresión no se ven afectados, con lo que se consigue una administración de la versión y de la réplica independientes. Esto también posibilita que el programa de sincronización sea más flexible. Para utilizar el archivado para realizar el seguimiento de los cambios de réplica, los datos de origen se deben registrar como versionados en la geodatabase corporativa y la versión de réplica de origen debe ser la versión predeterminada.
En el diagrama que aparece a continuación, se muestra una replicación unidireccional de principal a secundaria con archivado entre geodatabases corporativas, en la que se utiliza la versión predeterminada como versión de réplica tanto para la réplica principal como para la réplica secundaria en la geodatabase corporativa. Dado que los tipos de geodatabase personal y de archivos no admiten el versionado, no se crea ninguna versión de réplica en la geodatabase personal o de archivos secundaria.
La replicación unidireccional de secundaria a principal también se puede utilizar cuando ambas geodatabases son geodatabases corporativas. La versión de réplica secundaria debe ser la predeterminada en este caso.
