LENTIDAO BASE ACCESS E ADO
Olá!
Estou com o seguinte problema.
Tenho um sistema que utiliza banco de dados ACCESS 97, em ADO e utilizo a conexão JET 4.0.
Porem esta muito demorado para retornar os selects com mais de 30.000 registros, mas é demorado mesmo, em torno 30 segundos para um select simples, se fizer um select com mais de uma tabela, com distinct esta demorando 15 minutos.
Verifiquei que o JET 3.51 fica um pouco mais rapido, mas terei que realizar muitas alterações no sistema para rodar 100% e o custoXbeneficio não compensa.
Alguem poderia me dar alguma sugestão?
Grato
Estou com o seguinte problema.
Tenho um sistema que utiliza banco de dados ACCESS 97, em ADO e utilizo a conexão JET 4.0.
Porem esta muito demorado para retornar os selects com mais de 30.000 registros, mas é demorado mesmo, em torno 30 segundos para um select simples, se fizer um select com mais de uma tabela, com distinct esta demorando 15 minutos.
Verifiquei que o JET 3.51 fica um pouco mais rapido, mas terei que realizar muitas alterações no sistema para rodar 100% e o custoXbeneficio não compensa.
Alguem poderia me dar alguma sugestão?
Grato
Olha, ADO com Access fica lento mesmo... eu já comprovei isso. Se vc usar DAO, é mais rápido ou meno lento.
30 segundos é bastante tempo e 15 minutos nem se fala... você já verificou os Ãndices? As vezes, a forma como vc faz os selects influencia na velocidade.
A minha sugestão é pensar no futuro. Se vc for continuar com Access por MUITO tempo então é melhor ficar com DAO.
30 segundos é bastante tempo e 15 minutos nem se fala... você já verificou os Ãndices? As vezes, a forma como vc faz os selects influencia na velocidade.
A minha sugestão é pensar no futuro. Se vc for continuar com Access por MUITO tempo então é melhor ficar com DAO.
Marcos.
Já verifiquei a questão dos indices, reparei que acima de 15.000 registros começa a ficar lento o sistema.
Pretendo mudar para SQL, mas não é um processo rapido e tenho urgencia nesta solução, com DAO fica mais rapido, mas não pretendia realizar esta alteração, já que usarei mais tarde o SQL.
Teria mais alguma sugestão?
Já verifiquei a questão dos indices, reparei que acima de 15.000 registros começa a ficar lento o sistema.
Pretendo mudar para SQL, mas não é um processo rapido e tenho urgencia nesta solução, com DAO fica mais rapido, mas não pretendia realizar esta alteração, já que usarei mais tarde o SQL.
Teria mais alguma sugestão?
Olha, eu já manipulei mais de 1 milhão de registros no access com DAO e não ficava tão lento assim...
As querys são muito complexas?
Ou só o fato de consultar utilizando apenas uma tabela já fica lento?
As querys são muito complexas?
Ou só o fato de consultar utilizando apenas uma tabela já fica lento?
Já que ainda pretende utilizar o ACCESS, experimenta converter uma cópia da base para 2000, afim de realizar outros testes de desempenho.
realmente é muito complicado o fluxo de dados das bases de dados do MS Access, a melhor base dados Access atualmente é a 2007 12.0
seu fluxo de dados é semelhante a do data file sql server 2005 ,
porem não adianta nada se usa estrutura de base de dados não foi bem projetada para os requisitos de sua aplicação.
exemplo: atribuir a um campo de CEP (300 varchar) não pode fazer isso. sendo que um campo de CEP contem no máximo 8 varchar.
trabalhar com dados certos é chave para sobrevivência de uma base de dados access. eu não trabalho mas com access nem com vb6 mas ja trabalhei muito tempo e sei como da trabalho fazer um base access resisti no máximo cinco anos sem nenhum backup.
seu fluxo de dados é semelhante a do data file sql server 2005 ,
porem não adianta nada se usa estrutura de base de dados não foi bem projetada para os requisitos de sua aplicação.
exemplo: atribuir a um campo de CEP (300 varchar) não pode fazer isso. sendo que um campo de CEP contem no máximo 8 varchar.
trabalhar com dados certos é chave para sobrevivência de uma base de dados access. eu não trabalho mas com access nem com vb6 mas ja trabalhei muito tempo e sei como da trabalho fazer um base access resisti no máximo cinco anos sem nenhum backup.
Tópico encerrado , respostas não são mais permitidas