REPLICATE

El comando REPLICATE permite replicar los datos de una tabla de una base A en la de una tabla de una base B. Por convención, la base donde se ejecuta el comando se llama "base local" y la base de la cual los datos se replican se llama "base remota".

Este comando sólo puede utilizarse en el marco de un sistema de replicación de base. Para que el sistema funcione, la replicación debe haber sido activada en la base local y en la base remota y cada tabla implicada deberá tener una llave primaria. Para mayor información sobre este sistema, consulte la sección Replicación vía SQL.

Nota: si desea implementar un sistema de sincronización completo, consulte la descripción del comando SYNCHRONIZE.

Pase una lista de campos (virtuales o estándar), separados por comas en lista_replicada. Los campos deben pertenecer a la tabla ref_tabla de la base remota.
La cláusula FROM debe ir seguida de un argumento del tipo ref_tabla que permite designar la tabla de la base remota desde la cual replicar los datos de los campos lista_replicada.

Nota: los campos virtuales de la tabla remota sólo se pueden almacenar en los arrays de la base local.

La cláusula opcional WHERE permite aplicar un filtro preliminar a los registros de la tabla en la base de datos remota; sólo aquellos registros que cumplan los criterios_de_búsqueda serán tenidos en cuenta por el comando.

4D recupera los valores de los campos lista_replicada para todos los registros designados por la cláusula FOR REMOTE STAMP. El valor pasado en esta cláusula puede ser:

• Un valor de tipo entero largo > 0: en este caso, se recuperan los registros donde el valor de __ROW_STAMP es mayor o igual a este valor.
• 0: en este caso, se recuperan todos los registros donde el valor de __ROW_STAMP es diferente de 0. Tenga en cuenta que los registros que existían antes de la activación de la replicación, no serán tenidos en cuenta (el valor de __ROW_STAMP = 0).
• -1: en este caso, todos los registros de la tabla remota se recuperan, es decir, todos los registros donde el valor de __ROW_STAMP >= 0. A diferencia del caso anterior, se tendrán en cuenta todos los registros de la tabla, incluidos los que existían antes de la activación de la replicación.
• -2: En este caso, se recuperan todos los registros borrados de la tabla remota (después de la activación de la replicación), es decir, todos los registros donde el valor de __ROW_ACTION = 2.

Por último, puede aplicar a la selección obtenida las cláusulas opcionales OFFSET  y/o LIMIT:

• Cuando se pasa, la cláusula OFFSET permite ignorar los primeros X registros de la selección (donde X es el valor pasado a la cláusula).
• Cuando se pasa, la cláusula LIMIT permite restringir la selección a los Y primeros registros de la selección (donde Y es el valor pasado a la cláusula). Si la cláusula OFFSET también se pasa, la cláusula LIMIT se aplica a la selección obtenida tras la ejecución de OFFSET.

Una vez aplicadas ambas cláusulas, la selección resultante se envía a la base local.

Los valores recuperados se escriben directamente la lista_objetivo de la base local o en los campos estándar especificados por nom_sql de la tabla ref_tabla de la base local.
El argumento lista_objetivo puede contener una lista de campos estándar o una lista de arrays del mismo tipo que los campos remotos (pero no una combinación de ambos). Si el destino del comando es una lista de campos, los registros objetivos serán creados, modificados o eliminados automáticamente en función de la acción almacenada en el campo virtual __ROW_ACTION.

Los conflictos para los registros replicados que ya existen en la base objetivo (llaves primarias idénticas) se resuelven utilizando las cláusulas de prioridad (opción REMOTE OVER LOCAL y LOCAL OVER REMOTE):  

• Si  pasa la opción REMOTE OVER LOCAL u omite la cláusula de prioridad, todos los registros fuente (base remota) designados por la cláusula FOR REMOTE STAMP reemplazan los registros objetivo (base local) si ya existen, cambiados o no de un lado o del otro. En este caso, no tiene sentido pasar una cláusula LOCAL STAMP porque se ignorará.
• Si pasa la opción LOCAL OVER REMOTE, el comando tiene en cuenta el marcador local LOCAL STAMP. En este caso, los registros objetivo (base local) cuyo valor de marcador es inferior o igual al pasado en LOCAL STAMP no son remplazados por los registros fuente (base remota). Por ejemplo, si pasa 100 en LOCAL STAMP, todos los registros de la base local cuyo marcador sea menor o igual a 100 serán remplazados por los registros equivalentes de la base remota. Este principio permite preservar los datos modificados localmente y reducir la selección de los registros a replicar en la tabla local.
• Si pasa las cláusulas LATEST REMOTE STAMP y/o LATEST LOCAL STAMP, 4D devuelve en las variables ref_lenguaje_4D correspondientes los valores de los últimos marcadores de las tablas local y remota. Esta información puede ser útil si desea personalizar la gestión del procedimiento de sincronización. Estos valores corresponden al valor de los marcadores inmediatamente después de terminada la operación de replicación: si los utiliza en una instrucción REPLICATE o SYNCHRONIZE, no es necesario incrementarlos porque son incrementados automáticamente antes de ser devueltos por el comando REPLICATE.

Si la operación de replicación se lleva a cabo correctamente, la variable sistema OK toma el valor 1. Puede controlar este valor desde un método 4D.

Si se producen errores durante la operación de replicación, la operación se detiene cuando ocurra el primer error. La última variable fuente (si se ha especificado) toma el valor con el marcador del registro en el que se produjo el error. La variable sistema OK toma el valor 0. El error generado puede interceptarse por un método de gestión de errores instalado por el comando ON ERR CALL.

Nota: las operaciones efectuadas por el comando REPLICATE no tienen en cuenta las restricciones de integridad de datos. Esto significa, por ejemplo, que las reglas que rigen las llaves foráneas, unicidad, etc. no son verificadas. Si los datos recibidos pueden afectar la integridad de los datos, debe comprobar los datos después de la operación de replicación.  La manera más simple es bloquear, vía el lenguaje 4D o SQL, los registros que se tienen que modificar.