Temos um banco de dados do Access que reside em um servidor em uma pasta compartilhada.
Alguns meses atrás, o banco de dados não podia ser aberto devido a mensagens de erro como:
- O documento causou um erro grave na última vez em que foi aberto.
- O Microsoft Access detectou que este banco de dados está em um estado inconsistente e tentará recuperá-lo.
Consegui corrigir o problema executando um "Compactar e reparar" do Access e isso parece ter resolvido.
O problema continuou acontecendo, porém, e toda vez que isso acontece, eu executo o mesmo procedimento:
- Vá para o servidor com o arquivo compartilhado e, no Gerenciamento do Computador, feche todas as conexões "Arquivos Abertos" para o arquivo e a pasta.
- Abra o banco de dados e execute o "Compact and Repair"
- Se o banco de dados criou um arquivo de backup, geralmente chamado de "Backup de [Nome do arquivo original]", mova-o para uma pasta separada para evitar confusão sobre qual arquivo abrir.
Esse procedimento parece corrigir o problema todas as vezes, mas acho que isso não deveria ser feito constantemente. Algumas vezes, o erro ocorre algumas semanas após a última correção, mas às vezes isso acontece um dia após a última correção.
O que aprendi é que várias pessoas (geralmente no máximo 3-4 por vez) acessam esse banco de dados ao mesmo tempo, e não é incomum para quem o usa muito deixá-lo aberto o dia todo. Às vezes, vejo que os usuários o deixaram aberto por dias sem fechá-lo.
Existe algo que eu possa fazer para evitar que isso seja um problema recorrente? Talvez o Access não seja realmente feito para ser usado assim? Existe uma verificação para uma melhor consistência/soma de verificação para o banco de dados para evitar problemas?
Eu pesquisei e parece que isso é uma agulha no palheiro, pode ser uma série de problemas de rede ou outras coisas.
Espero poder orientá-lo na direção certa, porque você não forneceu informações sobre a configuração (rede/como o Access está configurado):
O mecanismo de banco de dados Jet/ACE é, por padrão, multiusuário -- ele foi desenvolvido desde o início para ser assim. Então isso pode ser descartado como causa
Compartilhar um armazenamento de dados Jet/ACE é muito confiável quando a rede está no nível padrão. Padrão significa LAN sobre cabo (Não WAN / DialIn e NÃO wireless, porque a largura de banda deve ser suficiente para Jet/ACE manter o arquivo LDB - para bloqueio multiusuário)
O uso normal do banco de dados significa um ping pelos PCs locais instância do mecanismo de banco de dados Jet/ACE uma vez por segundo (usando-o com as configurações padrão) e porque o Jet/ACE não pode se recuperar de uma queda de conexão (o que pode ser um evento comum em um ambiente sem fio). usuários em WiFi e antes em ambiente "cabeado" ou aqueles "deixando o acesso aberto por dias" são via WiFi, você deve verificar isso
O caso de problema em que o Access falha com "grandeza" é quando um MDB de aplicativo front-end do Access é compartilhado. A razão pela qual ele falha é porque você está compartilhando coisas que não podem ser compartilhadas de forma confiável e não têm motivo para serem compartilhadas. Devido à maneira como os objetos do Access são armazenados em um arquivo MDB (todo o projeto do Access é armazenado em um único campo BLOB em um registro em uma das tabelas do sistema), é muito propenso a corrupção se vários usuários o abrirem. Compartilhar um front-end do Access (ou um MDB não dividido com tabelas e formulários/relatórios/etc. tudo em um MDB) é a fonte de 95% das corrupções de arquivos Access/Jet/ACE. - Se for esse o caso, considere reescrever as partes cruciais de seu aplicativo.
Muito raramente aconteciam casos com a instalação de um novo SW de antivírus ou atualização de SW no servidor - isso era causado pelo bloqueio de arquivos do mecanismo JET/ACE para causar estragos. Felizmente, isso pode ser facilmente identificado examinando os logs de eventos no servidor e obtendo um patch do fornecedor do SW que corrigiu o problema em quase todos os casos (ao ter um AV-SW top-10, muitas empresas são afetadas, então o problema é resolvido rapidamente)
E sim, alguns de meus clientes no passado argumentaram sempre ao atingir o cenário 2 ou 3 "Mas funcionou até agora" ou "fizemos assim ao longo de alguns anos". Em vez de entrar em uma análise prolixo por que começar com um determinado ponto no tempo (principalmente devido à adição de formulários/consultas ou mais usuários usaram WiFi) começou a falhar, removi o problema e tudo funcionou bem a partir de então.
EDIT
A rede do OP está passando por alguns andares/prédios. Isso não deve ser problema, desde que a rede seja confiável (= a conexão na rede permanece estável - portanto, o reenvio de pacotes NÃO é um problema para o Access). Ou para expressá-lo na palavra OPs
Não, isso pode ser descartado. Mas se forem usados elementos MAN/WAN HW (como conectores GSM/UMTS/LTE, VPN over the air, apenas peças de rede conectadas por antena ou similares), isso pode causar problemas - Aqui apenas uma análise aprofundada de seus logs pode ajudar ou uma rede teste com logon. Você faria muitos pings com falha/pacotes reenviados em um curto período de tempo, não o ruído usual de erros ocasionais que você tem em qualquer rede, mas para conexões perdidas/redefinidas, reconexão a um servidor, etc., enquanto trabalhava no Access
The OP comentou que tudo está em um arquivo grande (banco de dados e frontend). Para resolver isso, você deve dividir o banco de dados. Aqui está um exemplo: Como dividir um banco de dados do Access