Pergunta

Estou usando o Access 2003 em uma máquina duo-core com 4 GB de RAM, executando o Windows XP (Service Pack 3) [5.1.2600]

Periodicamente, recebo uma mensagem de erro "Não há memória suficiente para executar esta operação.Feche os programas desnecessários e tente a operação novamente."

Uma verificação no Gerenciador de Tarefas indica que há bastante memória livre.Fechar outros programas abertos não faz diferença.

Isso acontece esporadicamente e em diferentes circunstâncias:às vezes, ao salvar alterações no design do formulário ou no código VBA, às vezes, quando vários formulários estão abertos e em uso.

Se tentar salvar alterações de design e esse erro ocorrer, os objetos do Access estarão corrompidos e não poderão ser recuperados.

Qualquer sugestão sobre o que pode estar causando isso seria muito bem-vinda.

MTIA

Foi útil?

Solução 6

Como sei que são formas ou relatórios que provavelmente são corrompidos, criei um novo MDB e apenas as tabelas importadas (anexadas), consultas, scripts (apenas um), módulos e menus. Em seguida, usei o LoadFromText para importar formulários e relatórios por meio de uma função e, em seguida, fiz o decompilo/compilação usual e compactar/reparar etc.

Até agora, toque em madeira, eu não tive outro acidente há alguns dias, então provavelmente continuarei com esse método de recuperação.

Muito obrigado a todos por suas sugestões.

Outras dicas

O projeto VBA no seu front -end provavelmente está corrompido. Você precisa reconstruí -lo do zero e usar práticas de codificação de acesso adequadas:

  1. Nas opções VBE, desligue a compilação sob demanda (ver Artigo de Michael Kaplan no decompile Para detalhes do porquê).

  2. Nas opções do VBE, ativar a declaração variável.

  3. No VBE, personalize sua barra de ferramentas para que o botão de compilação seja facilmente acessível (está no menu Debug). Eu também recomendo adicionar o botão de pilha de chamadas (no menu Exibir), pois é útil para erros de depuração no modo de interrupção. O ponto aqui é tornar a depuração e a compilação o mais fácil possível.

  4. Tendo configurado seu ambiente, analise todos os módulos do seu projeto recém -recuperado e adicione a opção explícita ao topo de todos os módulos que não têm. Então compile. Você descobrirá rapidamente onde você tem código inválido e precisará corrigi -lo.

  5. A partir de agora, ao programar, compilar frequentemente, após cada duas ou três linhas de código. Provavelmente compilar meu projeto 100 ou mais vezes por dia, quando codifica.

  6. Descompile periodicamente seu projeto e compacte e recompite -o. Isso limpará qualquer crud que se acumule durante o desenvolvimento regular.

Essas práticas garantem que o código em um projeto não corrupto permaneça no máximo possível uma condição. Não fará nada para recuperar um projeto já corrompido.

Em relação a como reconstruir o projeto, acho que seguiria a rota drástica de exportar todos os objetos com Application. Isso é superior a simplesmente importar do seu front -end corrompido existente, porque a importação pode importar estruturas corruptas que não sobreviverão a um ciclo de salvamento/carregamento do Cycle.

Eu programa diariamente em acesso, trabalhando com aplicativos não triviais que usam muito código, incluindo muitos módulos de classe independentes. Não perdi um objeto para codificar a corrupção em mais de 5 anos, e isso foi no dia em que ainda estava usando o A97.

Tendo tropeçado neste meu antigo post e visto que ele teve bastante interesse, pensei que talvez uma atualização fosse necessária.

Então, 2 anos depois, fazendo muitos trabalhos em aplicativos de 2007, bem como aplicativos mais antigos de 2003 (e até mesmo de 97), estou descobrindo que 2007 é menos propenso a travamentos realmente desagradáveis ​​​​do que 2003 - onde as definições de objetos do Access (formulários e relatórios esp.) seriam facilmente corrompidos.

Eu ainda sigo religiosamente as sugestões 1-6 (acima) de David-W-Fenton, além do uso de Application.SaveAsText (veja a sugestão e o link de Tony Toews acima).

Hoje em dia, seja 97, 2003 ou 2007 em que estou trabalhando, se o Access der qualquer dica de "ser estranho | batendo | jogando erros inexplicáveis" etc, eu faço o seguinte:

  1. Feche imediatamente o aplicativo Access
  2. Faça backup do arquivo mdb/accdb
  3. Abra novamente o aplicativo enquanto mantém pressionado [Shift] para que nada seja executado
  4. Exporte todos os objetos como texto usando Application.SaveAsText (como outro backup)
  5. Feche e abra novamente o aplicativo usando a opção /decompile
  6. Recompilar o código VBA
  7. Faça um Compacto/Reparo.

Isso não resolve tudo, mas reduz significativamente o número de corrupções de objetos do Access, pelo que consigo observar.

Oh meu Deus.

Eu trabalhei em uma loja por muitos anos que usavam o acesso como plataforma de escolha. O aplicativo acabou sendo tão grande que começou a atingir uma limitação interna de memória do Access 2003. Eles começaram a enfrentar exatamente o mesmo problema que você está tendo. Como você notou, não há indicação externa de problemas de memória quando isso acontece.

A empresa conversou longamente com a Microsoft sobre o problema, e acredito que a Microsoft acabou lhes fornecendo um patch. Portanto, você pode querer conversar com a Microsoft sobre isso, se parecer uma situação semelhante ao que você está experimentando, pois eles poderão fornecer o mesmo patch.

Por fim, a solução de longo prazo é dividir a aplicação em pedaços menores. Mudar para o Access 2007 não ajudou; De fato, isso piorou as coisas porque o Access 2007 tem mais peças móveis.

Solução rápida; garantido para trabalhar:

VBA aberto (Alt-F11) Na janela imediata, digite o seguinte:

Application.SaveAsText acForm, "corrupt form name here", CurrentProject.Path & "\zzTempRevive"

então

Application.LoadFromText acForm, "corrupt form name here", CurrentProject.Path & "\zzTempRevive"

É isso :) Espero que isso ajude os outros!

Esta também é a mensagem de erro padrão quando o acesso não tem idéia de qual é o problema. Agora, se o seu MDB for particularmente grande, digamos mais de 800 formas e relatórios com módulos, sim, o MDB pode ser muito grande, embora isso lhe desse uma mensagem quando você foi criar MDEs. ACC2000: "Acesso à Microsoft não conseguiu criar uma mensagem de erro MDE"

Eu já tive isso aconteceu ocasionalmente. E meus MDBs atuais não são tão grandes. Observe que o compacto e o reparo não detectam erros em objetos que não sejam tabelas, índices ou relacionamentos. Portanto, importar para outro MDB é a única maneira de corrigir esses erros.

Você está trabalhando neste MDB sobre a rede? É sobre a única coisa que consigo pensar que pode causar esse problema.

Eu encontrei esse problema muitas vezes e finalmente encontrei uma solução que funcionou. Não sei o que causa o problema, mas sei como resolvê -lo.

Normalmente, o erro ocorre quando você abre um formulário. O que você precisa fazer é recriar completamente essa forma. A maneira mais fácil de fazer isso é exportar primeiro o formulário para um arquivo de texto com o aplicativo de função não documentado. Em seguida, você exclua o formulário do seu banco de dados e o relembra com o Application.LoadFromText.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top