Existe muita confusão sobre isto, então espero que este texto explique a todos exactamente porque é que é errado fazer isto.
Deixem-me começar por dizer que a REPLICAÇÃO é uma coisa muito gira. Deixa-te fazer coisas que simplesmente não há outra maneira de fazer. Este texto NÃO é uma flame contra a replicação, é uma flame contra as pessoas que tentam utilizá-la de uma maneira que ela não foi contruída para ser utilizada.... e apresenta muitas das razões porque é que as coisas que estão a fazer são perigosas para as suas aplicações e os dados que elas contêm.
************************************
OBJECTIVO DA REPLICAÇÃO: Possuir duas ou mais cópias de uma base de dados do Jet que são sempre consideradas como estando à distância de uma sincronização para serem idênticas. Diversas pessoas podem realizar alterações em múltiplas bases de dados, mas no fim todas as pessoas vão chegar ao ponto de "convergência" e será o mesmo. O suporte é para utilizadores conectados ou ocasionalmente conectados... mas não para utilizadores disconectados. A replicação do Microsoft Jet não suporta a possibilidade em que tu não possuires uma verdadeira conecção quer seja directa, indirecta, ou uma conecção por internet. Ponto Final.
************************************
MOVER/COPIAR BACKGROUND: Microsoft Jet, qualquer vez que abre uma réplica (para sincronização, ou a tua aplicação abre-a, ou qualquer outra coisa) vai determinar se a réplica foi movida. Efectua isto comparando a path e a máquina. Se determinar que não se encontra no mesmo sítio, vai assumir que tu copias-te a réplica e vai basicamente dar a esta réplica um novo ReplicaID (existem várias consequências graves em ter duas réplicas como o mesmo ReplicaID). Então, se tu tens um Conjunto de Réplicas com quatro réplicas, e tu moves a localização de uma réplica e depois a abres.... O Jet vai pensar que tu tens CINCO réplicas no conjunto de réplicas.
Isto aplica-se em qualquer das seguintes situações:
1) Mover uma réplica para uma disquete e depois utilizar essa disquete para poder trabalhar em casa ou em qualquer outro lugar
2) Directamente mover/copiar o ficheiro no DOS ou Explorer
3) Mover uma réplica através de um disco zip para que tu possas trabalhar nela através de duas máquinas/paths diferentes..... a não ser que os nomes das máquinas e path sejam idênticos, vai ser considerado pelo jet como sendo uma "cópia" mesmo que a deixes no disco zip e faças a sincronização a partir daí.
4) Enviar uma réplica por E-mail, para alguém
5) Qualquer outra maneira que te possas lembrar de copiar, desde fazer o download de um site na internet ou um share num servidor de ficheiros, etc.
Isto não se aplica nas seguintes situações:
1) Usando os métodos built-in para mover uma réplica, quer através do comando do Menu do Replication Manager ou do método MoveReplica do TSI Synchronizer.
2) O reconciliador da briefcase
Bem, este comportamento faz com que existam um bug, um incómodo, e três problemas by design que são REALMENTE MAUS e podem causar corrupção e/ou perdas de dados.
************************************
BUG #1: Existe um só e solitário bug no tratamento que o Jet faz destas coisas de "mudança do replicaID".... não efectua a limpeza da informação sobre qual é o Sincronizador que gere determinada réplica. Portanto, se tu utilizas o Sincronizador do Jet para replicação por Internet/Indirecta e copias uma réplica que é gerida para um outro local, Jet vai fazer uma nova réplica, mas ainda vai pensar que o antigo Sincronizador é que está a geri-la. Se não está, então podem ocorrer problemas quando tentas mais tarde fazer sincronizações. Se era uma réplica não-gerida, então não vais notar quaisquer problemas. Isto foi confirmado por pessoal interno da Microsoft como sendo um problema, mas como a situação não é suportada não foi considerado suficientemente importante para arriscar uma solução num service release. A solução é colocá-la como não-gerida, etc. ou criar uma nova réplica da maneira correcta e então vais ter uma não-gerida.
************************************
INCÓMODO #1: Á medida que vais movendo/copiando as réplicas, a lista de réplicas vai aumentando com o tempo e vais ver cada vez mais réplicas aparecer na (por exemplo) lista de réplicas existente em Access Tools|Replication|Synchronize e no Gestor de Replicação. Se tu estiveres sempre a copiar entre dois computadores então todas as réplicas ficticias vão ter os mesmos directórios.... podes então acabar por ter milhares de réplicas "c:\foo\bar.mdb" na lista. Remover estes itens não é trivial (no essencial jet somente marca como removido e propaga essa informação para as outras réplicas se te sincronizares com ele e ele conseguir encontrar o caminho mas não o ficheiro.... então se ele conseguir ver c:\foo\ mas não existir lá o bar.mdb, vai removê-lo. Se fizeres isto 1000 vezes, então irás remover as mil entradas. Existem outras maneiras imperfeitas de "remover" as réplicas ficticias que não são tão efecientes como esta.
************************************
PROBLEMA BY DESIGN #1: O Microsoft Jet 3.5x tem um limite de 64,000 sincronizadores que são "conhecidos" para uma réplica. Obviamente isto não é um problema para a maioria das aplicações, mas imagina que se não efectuares a gestão da réplica com um sincronizador, então o Jet cria um sincronizador "virtual" que tu podes utilizar para fazer a sincronização com um sincronizador real (muito bom para sincronizações pela internet e outras!). Isto significa que à medida que vais copiando, eventualmente vais chegar a ter 64,000 réplicas inválidas, e então estás feito, tu acabaste de estragar o teu conjunto de réplicas e não o podes arranjar sem ter de efectuar muito trabalho.
************************************
PROBLEMA BY DESIGN #2: Conflitos entre dados, que ocorrem quando duas pessoas tentam actualizar o mesmo registo, e são reportados na réplica em perda para o Jet 3.5. Então se tiveres uma réplica que perdeu num conflito, mas moveste-a (entre o intervalo de tempo que introduziste os dados e o momento em que realizaste a sincronização, altura em que os conflitos são reportados) a réplica, lembra-te que agora é uma NOVA réplica, e então tu perdeste todos os dados que estavam contidos nas tabelas de conflitos. Esta PERDA DE DADOS é obviamente muito séria.
************************************
PROBLEMA BY DESIGN #3: Erros de Dados, que ocorrem quando duas pessoas afectam a integridade da bd (a maneira mais fácil é quando duas pessoas põe a mesma chave primária para novos registos e depois fazem uma sincronização), são péssimas. De qualquer vez que fazes uma sincronização, o Jet assume que tu podes ter resolvido os problemas e vai "tentar de novo" a sincronização para ver se o problema já foi resolvido. Se descobre que o problema ainda está presente, vai parar a sincronização (e então não vai fazer mais nada e outros registos não são tranferidos). Como a informação reportada sobre um erro de dados está muito ligada à réplica de onde veio, etc., é MUITO mais Difícil descobrir a causa dos erros de dados quando a réplica em questão já lá não está... só existe um punhado de pessoas que eu conheça que foram capazes de resolver esta situação sem ter de recorrer a soluções extremas como des-replicar/voltar-a-replicar. De notar que as sincronizações NÃO estão a completar-se na integra quando existem erros de dados... portanto nem todas as réplicas vão obter todos os dados, e portanto estás num estado inconsistente. Tu não possuis qualquer controle sobre a ordem das operações onde tal acontece.
************************************
CODA: Finalmente, o cenário completo (visto que não é suportado) que nunca foram efectuados testes intensivos que outros cenários tiveram. Podemos gozar com os testes efectuados pela Microsoft aos seus produtos, mas o facto é que os testes intensivos são bastante cruciais e tendo eles nunca efectuado os mesmo significa que adicionando aos problemas acima descritos (que eu tenho vindo a descobrir, identificar, e resolver há muitos anos) podem existir outros problemas que ainda não foram descobertos. Ironicamente, as pessoas que mais critiraram a MS pelos erros nos seus produtos vão ignorar esta queixa.
Para que fique registado, antes da replicação do Jet estar disponível, no Jet 3.0, NENHUM dos anteriormente descritos problemas era conhecido ou compreendido. MESMO ASSIM eu sempre aconselhei as pessoas que nunca deviam copiar ou mover uma réplica que contivesse dados, nunca. A razão é que *EU* sigo o seguinte conselho onde nunca efectuo coisas que não são suportadas. Como tal, eu nunca tive uma aplicação que onde tivesse ocorrido QUALQUER destes problemas. Contudo, eu pessoalmente já estive envolvido em ajudar na recuperação de acima de 70 diferentes aplicações, nos últimos anos, que tiveram problemas graves somente relacionados com os problemas descritos aqui. O total dos custos estimados para o cliente é ALTO, bem como as pessoas teimosamente insistem em realizar isto, ignorando completamente todos os avisos.
************************************
Então, porque não "Ser como o Mike" :-) e simplesmente não tentar fazer coisas que não são suportadas e não estão testadas, especialmente quando neste momento foi provado que podem causar problemas muito grandes?
