REPLICATE

O comando REPLICATE permite replicar os dados de uma tabela de uma base A na de uma tabela de uma base B. Por convenção, a base onde é executado o comando se chama "base local" e a base da qual os dados se replicam se chama "base remota".

Este comando só pode ser utilizado no marco de um sistema de replicação de base. Para que o sistema funcione, a replicação deve ter sido ativada na base local e na base remota e cada tabela implicada deverá ter uma chave primaria. Para maior informação sobre este sistema, consulte a seção Replicação via SQL.

Nota: Se deseja implementar um sistema de sincronização completo, consulte a descrição do comando SYNCHRONIZE.

Passe uma lista de campos (virtuais ou padrão), separados por vírgulas em lista_replicada. Os campos devem pertencer a tabela ref_tabela da base remota.
A cláusula FROM deve ir seguida de um argumento do tipo ref_tabela que permite designar a tabela da base remota desde a qual replicar os dados dos campos lista_replicada.

Nota: Os campos virtuais da tabela remota só podem ser armazenadas nos arrays da base local.

A cláusula opcional WHERE permite aplicar um filtro preliminar aos registros da tabela no banco de dados remoto; só aqueles registros que cumpram com os critérios_de_pesquisa serão levados em consideração pelo comando.

4D recupera os valores dos campos lista_replicada para todos os registros designados pela cláusula FOR REMOTE STAMP. O valor passado nesta cláusula pode ser:

• Um valor de tipo inteiro longo > 0: neste caso, são recuperados os registros onde o valor de __ROW_STAMP é maior ou igual a este valor.
• 0: Neste caso, se recuperam todos os registros onde o valor de __ROW_STAMP é diferente de 0. Leve em conta que os registros que existiam antes da ativação da replicação, não serão levados em consideração (o valor de __ROW_STAMP = 0).
• -1: Neste caso, todos os registros da tabela remota se recuperam, ou seja, todos os registros onde o valor de __ROW_STAMP >= 0. A diferença do caso anterior, serão levados em consideração todos os registros da tabela, inclusive os que existiam antes da ativação da replicação.
• -2: Neste caso, se recuperam todos os registros excluídos da tabela remota (depois da ativação da replicação), ou seja, todos os registros onde o valor de __ROW_ACTION = 2.

Por último, você pode aplicar a seleção obtida para as cláusulas opcionais OFFSET  e/ou LIMIT:

• Quando passada, a cláusula OFFSET permite ignorar os primeiros X registros da seleção (onde X é o valor passado a cláusula).
• Quando passada, a cláusula LIMIT permite restringir a seleção aos Y primeiros registros da seleção (onde Y é o valor passado a cláusula). Se a cláusula OFFSET também passa, a cláusula LIMIT se aplica a seleção obtida através da execução de OFFSET.

Uma vez aplicadas ambas cláusulas, a seleção resultante se envia a base local.

Os valores recuperados se escrevem diretamente a lista_objetivo da base local ou nos campos padrão especificados por nom_sql da tabela ref_tabela da base local.
O argumento lista_objetivo pode conter uma lista de campos padrão ou uma lista de arrays do mesmo tipo que os campos remotos (mas não uma combinação de ambos). Se o destino do comando é uma lista de campos, os registros objetivos serão criados, modificados ou eliminados automaticamente em função da ação armazenada no campo virtual __ROW_ACTION.

Os conflitos para os registros replicados que já existem na base objetivo (chaves primárias idênticas) se resolvem utilizando as cláusulas de prioridade (opção REMOTE OVER LOCAL e LOCAL OVER REMOTE):  

• Se  passar a opção REMOTE OVER LOCAL omite a cláusula de prioridade, todos os registros fonte (base remota) designados pela cláusula FOR REMOTE STAMP substituem os registros objetivo (base local) se já existem, trocados ou não de um lado ou do outro. Neste caso, não tem sentido passar uma cláusula LOCAL STAMP porque será ignorada.
• Se passar a opção LOCAL OVER REMOTE, o comando leva em conta o marcador local LOCAL STAMP. Neste caso, os registros objetivo (base local) cujo valor de marcador é inferior ou igual ao passado em LOCAL STAMP não são substituídos pelos registros fonte (base remota). Por exemplo, se passar 100 em LOCAL STAMP, todos os registros da base local cujo marcador seja menor ou igual a 100 serão substituídos pelos registros equivalentes da base remota. Este princípio permite preservar os dados modificados localmente e reduzir a seleção dos registros a replicar na tabela local.
• Se passar as cláusulas LATEST REMOTE STAMP e/ou LATEST LOCAL STAMP, 4D devolve nas variáveis ref_linguagem_4D correspondentes os valores dos últimos marcadores das tabelas local e remota. Esta informação pode ser útil se deseja personalizar a gestão do procedimento de sincronização. Estes valores correspondem ao valor dos marcadores imediatamente depois de terminada a operação de replicação: se os utiliza em uma instrução REPLICATE ou SYNCHRONIZE, não é necessário executar porque são incrementados automaticamente antes de ser devolvidos pelo comando REPLICATE.

Se a operação de replicação é levada a cabo corretamente, a variável sistema OK toma o valor 1. Pode controlar este valor desde um método 4D.

Caso sejam produzidos erros durante a operação de replicação, a operação é detida quando ocorra o primeiro erro. A última variável fonte (caso especificado) toma o valor com o marcador do registro no qual foi produzido o erro. A variável sistema OK toma o valor 0. O erro gerado pode ser interceptado por um método de gestão de erros instalado pelo comando ON ERR CALL.

Nota: As operações realizadas pelo comando REPLICATE não tem em conta as restrições de integridade de dados. Isto significa, por exemplo, que as regras que regem as chaves externas, singularidade, etc. não são verificadas. Se os dados recebidos podem afetar a integridade dos dados, deve comprovar os dados depois da operação de replicação.  A forma mais simples é bloquear, via a linguagem 4D ou SQL, os registros que devem ser modificados.