sincronização de dados - MS Access

StackOverflow https://stackoverflow.com/questions/1801658

  •  05-07-2019
  •  | 
  •  

Pergunta

Eu tenho um problema no momento em que vários (mesmo esquema) bancos de dados do Access 2003 são usados ??em laptops.

Eu preciso encontrar uma maneira automatizada para sincronizar os dados em um banco de dados de acesso central.

Os dados sobre os laptops só é anexado ao modo de atualização / operações de exclusão não vai ser um problema.

Quais as ferramentas me permite fazer isso facilmente? Quais os fatores que vão afetar a decisão sobre a melhor ferramenta ou solução?

Foi útil?

Solução

É possível usar a replicação Jet embutido no Access, mas vou avisá-lo, é muito esquisito. Ele também irá atrapalhar o seu PK em qualquer tabelas que você fazê-lo em porque ele escolhe aleatoriamente inteiros assinado para tentar evitar colisões chave, então você pode acabar com -1243482392912 como seu próximo PK em um determinado registro. Isso é um PITA para digitar se você estiver fazendo qualquer tipo de pesquisa sobre ele (como um ID do cliente, número de ordem, etc.) Você não pode sincronização Acesso automatizar (talvez você pode fingir algo parecido usando VBA. Mas ainda , que só será executado quando o banco de dados é aberto).

A maneira que eu recomendo é usar SQL Server 2005/2008 em seu banco de dados "central" e usar Edições SQL Server Express como o back-end em seus "remotos" bancos de dados, em seguida, usar tabelas vinculadas no Access para conectar a esses bancos de dados SSEE e replicação para sincronizá-los. Configurar quer replicação de mesclagem ou instantâneo replicação com seu banco de dados "central" como o editor e seus bancos de dados SSEE como assinantes. Ao contrário de replicação Access Jet, você pode controlar a numeração PK mas para você, isso não será um problema como seus assinantes não estará empurrando alterações.

Além da escalabilidade que servidor SQL traria, você também pode automatizar isso usando o Gerenciador de sincronização do Windows (se você sincronizou pastas, essa é a pequena caixa chata que aparece e sincroniza-los quando você logon / logoff), e defini-lo para que ele sincroniza em um determinado intervalo, na inicialização, desligamento, ou em uma hora do dia, e / ou quando o computador está ocioso, ou sincroniza somente sob demanda. Mesmo se o Access não é executado por um mês, o seu conjunto de dados pode ser atualizado a cada vez que seus usuários se conectam à rede. Muito legal coisas.

Outras dicas

Replication O acesso pode ser difícil, e como você só exigem consultas acréscimo com alguns testes, provavelmente seria melhor para escrever algo sozinho. Se os dados recolhidos por cada laptop não podem se sobrepor, isso pode não ser muito difícil.

Você vai precisar de considerar as chaves primárias. Pode ser o melhor para incorporar o nome de usuário ou laptop na chave para garantir que os registros relacionar corretamente.

As respostas neste tópico são preenchidos com informações erradas sobre replicação Jet de pessoas que obviamente não tê-lo usado e estão apenas repetindo coisas que se ouviram, ou estão atribuindo problemas para replicação Jet que realmente refletem erros de projeto de aplicação.

É possível usar o Jet replicação incorporadas ao Access, mas eu irá avisá-lo, é muito esquisito.

Jet Replication não é flakey. É perfeitamente confiável quando usado corretamente, assim como qualquer outra ferramenta complexa. É verdade que certas coisas que não causam problemas em um banco de dados não replicado pode levar a problemas quando replicado, mas que está a razão por causa da natureza do que a replicação pela qualquer implica motor de banco de dados.

Ele também irá atrapalhar o seu PK em o que quer tabelas que você fazê-lo em causa ele pega assinado inteiros aleatórios para tentar e evitar colisões chave, então você pode acabar com -1243482392912 como seu próxima PK em um determinado registro. Aquilo é um PITA para digitar se você estiver fazendo qualquer tipo de pesquisa sobre ele (como um cliente ID, número de ordem, etc.)

Surrogate Autonumber PKs nunca deve ser exposto a usuários em primeiro lugar. Eles são números sem sentido usados ??para unir os registros nos bastidores, e se você está expondo-os a usuários É um erro em seu design do aplicativo.

Se você fizer números de seqüência precisa, você vai ter que rolar o seu próprio e lidar com a questão de como evitar colisões entre as suas réplicas. Mas isso é um problema para replicação em qualquer motor de banco de dados. SQL Server oferece a capacidade de alocar blocos de números de seqüência para réplicas individuais no nível de banco de dados e isso é um recurso muito bom, mas ele vem com o custo de maior sobrecarga administrativa de manter várias instâncias do SQL Server (com todas as questões de segurança e desempenho que implica). Na replicação Jet, você teria que fazer isso no código, mas isso é quase uma questão complicada.

Uma outra alternativa seria a utilização de um composto de PK, onde uma coluna indica a réplica de origem.

Mas isso não é uma falha na implementação de replicação do Jet - é um problema para qualquer cenário de replicação com uma necessidade de seqüência números significativos

.

Você não pode automatizar o Access sincronização (talvez você pode fingir algo parecido usando VBA. mas ainda, que só será executado quando o banco de dados é aberto).

Isto é obviamente falso. Se você instalar o Jet sincronizador você pode programar synchs (diretos, indiretos synchs ou Internet). Mesmo sem ele, você poderia marcar uma VBScript para serem executados periodicamente e fazer a sincronização. Esses são apenas dois métodos de realizar automatizado synchroniziation Jet sem a necessidade de abrir o seu aplicativo de acesso.

A citação de documentação MS:

Use Jet e objectos de replicação

JRO não é realmente a melhor maneira de gerenciar Jet Replication. Por um lado, ele tem apenas uma função em que ela própria não tem DAO, isto é, a capacidade de iniciar uma sincronização indirecta em código. Mas se você estiver indo para adicionar uma dependência para a sua aplicação (JRO requer uma referência, ou pode ser usado através de ligação tardia), assim como você pode adicionar uma dependência em uma biblioteca verdadeiramente útil para controlar Jet Replication, e essa é a TSI Synchronizer , criado por Michael Kaplan, uma vez que o maior especialista do mundo em Jet Replication (que, desde então, mudou-se para a internacionalização como sua área de concentração). Dá-lhe o controle programático completo de quase toda a funcionalidade de replicação que expõe Jet, incluindo synchs agendamento, iniciar todos os tipos de sincronização, e o comando MoveReplica muito necessária (a única maneira legal de se mover ou renomear uma réplica sem quebrar replicação).

JRO é um dos enteados feias de abortada campanha ADO-Everywhere da Microsoft. Sua finalidade é fornecer funcionalidade específica do Jet para complementar o que é suportado em si ADO. Se você não estiver usando ADO (e você não deve estar em um aplicativo de acesso com um back-end Jet), então você realmente não quer usar JRO. Como eu disse acima, ele adiciona apenas uma função que não está já disponível no DAO (ou seja, iniciar uma sincronização indireta). Eu não posso deixar de pensar que a Microsoft estava sendo maldosa criando uma biblioteca independente para funcionalidades específicas do Jet e, em seguida, propositadamente deixando de fora todas as funções incrivelmente úteis que eles poderiam ter suportado se tivessem escolhido.

Agora que eu eliminados das afirmações errôneas nas respostas oferecidas acima, aqui é a minha recomendação:

Porque você tem uma infra-estrutura append-only, fazer o que @Remou recomendou e criar algo para enviar manualmente os novos registros onde quer que eles precisam ir. E ele está certo de que você ainda tem que lidar com a questão PK, assim como você faria se você usou Jet Replication. Isto é porque isso é ditadas pela necessidade de adicionar novos registros em vários locais, e é comum a todas as aplicações de replicação / sincronização.

Mas uma ressalva: se o cenário só de add muda no futuro, você vai ser lavado e ter que começar do zero ou escrever um monte de código cabeludo para gerenciar exclusões e atualizações (isso não é fácil - confiança mim, eu fiz isso!). Uma vantagem de usar apenas Jet Replication (mesmo que seja mais valioso para sincronizações bidirecionais, ou seja, as edições em vários locais) é que ele vai lidar com o cenário só de add sem problemas, e depois lidar facilmente com replicação de mesclagem completa caso seja uma exigência no futuro.

Último de tudo, um bom lugar para começar com replicação Jet é a Jet Replication Wiki . Os recursos, melhores práticas e as coisas não acreditar páginas são provavelmente os melhores lugares para começar.

Você deve ler em Acesso Banco de Dados Replication , como há algumas informações lá fora.

Mas eu acho que, para que ele funcione corretamente com o seu aplicativo, você terá para a implantação de uma solução personalizada feita usando o métodos e propriedades disponível para esse efeito.

Use Jet e objectos de replicação (JRO) Se você precisar de controle programático sobre o intercâmbio de dados e informações de projeto entre os membros do conjunto de réplicas em bancos de dados do Microsoft Access (arquivos .mdb apenas). Por exemplo, você pode usar JRO para escrever um procedimento que sincroniza automaticamente réplica de um usuário com o resto do conjunto quando o usuário abre o banco de dados. Para replicar um banco de dados por meio de programação, banco de dados deve ser fechado.

Se o seu banco de dados foi criado com o Microsoft Access 97 ou anterior, você deve usar o Data Access Objects (DAO) para programaticamente replicar e sincronizar-lo.

Você pode criar e manter um banco de dados replicado nas versões anteriores do Microsoft Access usando métodos DAO e propriedades. Use DAO se você precisar de controle programático sobre a troca de informações de dados e design entre os membros do conjunto de réplicas. Por exemplo, você pode usar DAO para escrever um procedimento que automaticamente sincroniza réplica de um usuário com o resto do conjunto quando o usuário abre o banco de dados.

Você pode usar os seguintes métodos e propriedades para criar e manter um banco de dados replicado:

  • método MakeReplica
  • método Synchronize
  • propriedade ConflictTable
  • propriedade DesignMasterID
  • propriedade KeepLocal
  • propriedade Replicable
  • propriedade ReplicaID
  • propriedade ReplicationConflictFunction

Microsoft Jet fornece estes métodos e propriedades adicionais para a criação e manutenção réplicas parciais (réplicas que contêm um subconjunto dos registos de uma réplica completa):

  • propriedade ReplicaFilter
  • propriedade PartialReplica
  • método PopulatePartial

Você deve definitivamente ler o Sincronizando dados parte da documentação .

Eu costumava replicação em a00 por anos, até obrigados a atualizar a A07 (quando ele foi embora). A questão mais problemática que funcionou em, ao nível da empresa, estava administrando os CONFLITOS . Se não for gerida oportuna, ou há muitos, os usuários ficam frustrados e os dados torna-se confiável.

Replication fez um trabalho bem quando nossos sites remotos não foram sempre conectado à internet. Isto permitiu-lhes trabalhar com os seus dados, e sincronizar quando podiam. Pelo menos duas vezes por dia.

Nós instalar um banco de dados separado nos computadores remotos que conseguiram a sincronização, para que o usuário só tinha de clicar em um ícone na sua área de trabalho para evocar a sincronização.

O usuário tinha um botão separado para envio / recepção no alimenta um arquivo FTP designada que vai atualizar a partir dos sistemas legados.

Este processo funcionou muito bem, como tivemos 30 desses "nós" que trabalham em todo o país, a gestão de seus dados e atualização para os servidores FTP.

Se você está considerando seriamente este caminho, deixe-me saber e eu posso lhe enviar minha documentação.

Você pode escrever seu próprio software de sincronização que se conecta ao laptop seleciona o diff a partir dele do db e inserções ao mestre. É depende de seu esquema de dados como fácil esta operação será. (Se você tiver muitas tabelas com FKs ... você terá que fazê-lo de forma inteligente). Eu acho que vai ser o mais eficiente se você escrevê-lo sozinho.

Automatizar este tipo de comportamento é chamado de replicação e Accesss Suporta que, aparentemente, mas eu nunca vi isso implementado.

Como eu acho que a maioria das vezes o laptop não está conectado à DB principal não é uma boa idéia de qualquer maneira (com dados de replicação).

Se você vai olhar para uma ferramenta 3o partido para fazê-lo -. Olhar para algo que pode facilmente fazer o diff entre as tabelas antes de copiar, e pode fazê-lo de forma incremental é claro

FWIW:

  1. AutoNumbers. Concordo com David - eles nunca devem ser expostos. Para remover essa tentação, eu uso um autonumber aleatória.
  2. Replication. Eu usei esse extensivamente alguns anos atrás, com as sincronizações programadas, e usando GUIDs como o PK. Eu encontrei repetidamente que qualquer soluços através da rede corrompido as réplicas, com o resultado que eu tinha de dados de salvamento, e réplicas de re-assunto. ! Dolorosa
Não afiliado a StackOverflow
scroll top