O Access está se conectando a um banco de dados Postgresql remoto via ODBC utilizável?

Question

Atualmente, tenho um aplicativo do MS Access que se conecta a um banco de dados PostgreSQL via ODBC. Isso é executado com sucesso em uma rede local com 20 usuários (cada um executando sua própria versão do Access). Agora estou pensando em alguns cenários de recuperação de desastres, e parece que um método rápido e fácil de proteger os dados é usar o envio de logs para criar um modo de espera quente.

Isso me levou a pensar em colocar este warm-standby em um local remoto, mas então eu tenho a pergunta:

O acesso está se conectando a um banco de dados remoto via ODBC utilizável ? Ou seja o banco de dados remoto é talvez no mesmo país com tempos de ping ok e eu tenho uma linha SDSL de 1mbit.

    

Answer 1

Resposta curta: Sim.

Resposta longa: se você estiver retornando conjuntos de dados menores , sim. Você também precisará habilitar flags e configurações específicas no driver pgodbc, pois o Access irá separar o que é retornado para ele a partir do servidor:

O KSQO (otimização de consultas de conjunto de chaves) deve estar ativado. Sim, eu sei que os documentos dizem que não é necessário, mas o que está acontecendo é que o MSAccess está passando o SQL para o SQL. Isso apenas desorganiza a instrução SQL um pouquinho. Não acredita em mim? Ative a opção Logging for ODBC, envie uma única consulta, desligue o log, explore vários megas de lixo e 90% do caminho verá uma declaração SQL desagradável que foi gerada e passada. Não, não é o driver ODBC, é o Access fazendo isso.

Use Declare / Fetch deve estar ativado se você planeja analisar interativamente um grande conjunto de dados. Isso fará com que o driver busque pedaços menores do seu conjunto de resultados, em vez de despejar uma carga monstruosa nele.

Texto como LongVarChar - você pode testar isso. Eu suspeito que você vai querer "on".

Tamanhos Desconhecidos devem ser definidos como Máximo.

Recomenda-se que o

Max Varchar seja de 254 ou menos, embora você possa aumentá-lo.

Opts extra - definido como 0x6 (Falso MS SQL Server + Resposta em ANSI não Unicode).

(todos eles podem ser encontrados no link )

Tenha em mente que grandes conjuntos de dados causarão problemas, apesar do fato de os dados retornados do servidor estarem geralmente em um formato binário compacto.

    

Answer 2

Minha experiência com bancos de dados MSA e WAN nunca foi tão boa. Sempre houve algum momento em que o Access decidiu retirar muitos dados do banco de dados. As duas maneiras que obtive êxito foram colocar o front-end do Access no servidor remoto e usar o Terminal Server. Ou para usar as consultas SQL Passthrough de modo que você esteja explicitamente no controle do que é transmitido para / do servidor de banco de dados.

    

Answer 3

Para que um aplicativo do Access funcione bem neste cenário, ele deve ser arquitetado para recuperar os dados mínimos e provavelmente funcionaria melhor com formulários não vinculados, pois o Access / Jet / ACE precisa fazer ping no banco de dados remoto a cada segundo atualizando os dados exibidos em formulários encadernados. Como o intervalo de atualização do ODBC pode ser definido no Access, deve-se experimentar com isso antes de se tornar completamente desvinculado, pois isso significaria que você perderia 90% do benefício de usar o Access como front end.

Em geral, não vejo o cenário descrito como particularmente viável. Isso significaria a cauda abanando o cão, com seu plano de queda de desastre dirigindo o design do seu aplicativo regular. Eu diria que ter o Windows Terminal Server hospedando o aplicativo em algum lugar próximo ao servidor de banco de dados remoto seria uma solução muito melhor, já que não exigiria alterações significativas no aplicativo do Access.