[Resolvido]Access Utilizando tabela no PostgreSQL, Conexão ficou muito lenta

Senhores, devido a quantidade de dados, tive que utilizar o PostgreSQL como Back end. Como não tenho muito conhecimento na área, vinculei as tabelas pelo ODBC. Até funciona com tabelas pequenas, apesar da demora perceptível.

Ocorre que tenho uma tabela Principal com 4milhoes de registros, e mais 3 tabelas relacionadas a essa principal (essas não são problema, pois tem em media 30 registros cada).

Essas tabelas estão vinculadas pelo ODBC. Utilizo um formulário de pesquisa, onde o usuário irá digitar um valor e irei retornar no formulário continuo os registros que coincidem com o termo pesquisado, que na maioria das vezes será utilizado Like '*TermoPesquisado*'. Acontece que da forma como está, a consulta demora muito... Mas muito mesmo. Para me retornar 65 registros selecionados dentre os 4milhoes, demora em torno de 15min ou mais. Além do mais, os dados aparecem uma linha no formulário continuo, depois outro campo é preenchido... depois outro. Algo inutilizável.

Estou utilizando formulário vinculado a uma consulta que envolve essas três tabelas. Carrega sem dados para acelerar... O usuário digita o termo pesquisado e no click em um botao eu mudo a Origem dos dados de acordo com o filtro.
Os dados dessa tabela não será editado, apenas consultado. Devido a quantidade de dados não da pra ter ele no access pois excede o tamanho do Banco. O Servidor Postgre fica na mesma maquina que será utilizada o aplicativo localhost:5433.

Por não conhecer de ADO não consegui implantar para testes.
Office 2013.
PostgreSQL como Banco de dados.
Tabelas vinculadas por ODBC.
Necessito Consultar os dados dessa tabela.
Tabela principal possui 14 campos como data, texto curto e um principal que armazena texto longo(access).

Existem muitas dicas de conexões para ADO mas não consegui implantar nenhuma.
Grato pelas dicas.

UP

Boa tarde, Fábio
Já viu este

Código:

http://postgresonline.com/journal/archives/24-Using-MS-Access-with-PostgreSQL.html

?
Abraço,

Ola meu amigo, grato pela atenção!

Em minhas busca pela net, eu até cheguei a passar por esse link! Porem, em uma analise rápida eu cheguei a conclusão de que seria p mesmo que eu estou fazendo hj. Tabelas Vinculadas.

Mas agora lendo com mais calma, vi que vale testar dessa forma!

Assim que possível irei testar e retorno com o resultado!

Hoje fiz os testes sugerido! Porem não mudou em nada a velocidade dos dados!
Infelizmente, acredito que tenha algo errado ou é realmente incompatível PostgreSQL/Access. O interessante é que conectando Access a SQL Server, a conexão fica excelente, perdendo em pouco com conexão a Banco do Access. Muito estranho.

Fica a Duvida no ar...


Porém como o objetivo dessa conexão era apenas para consultas, e estava limitado aos 2GB do Banco Access... Resolvi da seguinte forma:

Dividi os registros em 3 Banco de dados Access: de 2000 a 2008 Banco1; de 2009 a 2014 Banco2 e de 2015 até hj Banco3. Ficou cada banco com mais ou menos 1,5GB e 1,3 milhões de registros.
*** Coloquei uma rotina de migração dos novos dados, para que seja atualizado todos os dias com os dados do dia anterior...

Assim, eu vinculei os tabelas no meu aplicativo;
No formulário de pesquisa o usuário escolhe em qual período irá realizar a pesquisa.
No botão de pesquisar eu muda origem dos dados para buscar no seu respectivo Banco de dados/Tabela (Me.RecordSource = stSQL).

A Velocidade ficou muito boa, apesar da quantidade de dados...
Único empecilho é que caso o usuário queira buscar nesses 17 anos, ele terá que fazer 3x a mesma pesquisa, porém ficou Funcional!

Dou como resolvido, mas caso alguém saiba a solução, por favor nos informe!

Olá Amigos,
Fábio, se a ideia é para pesquisa, porque não tem em Sql como pretendia em apenas uma tabela.
Apenas teria um formulário de pesquisa que só trazia os registos da pesquisa com os dados da pesquisa.
Resumindo o formulário de pesquisa quando abre não mostra dados, só quando coloca algum "dado" para filtro é que mostra.
Efetue um teste.

Abraço

Optei por usar Access pois a velocidade se utilizado dividido e ainda tudo em Access fica muito melhor. E por se tratar de muitos dados... e que continua crescendo...

Outro Fator é a licença do SQL SERVER.

Hoje esta dessa forma: ...formulário de pesquisa que só trazia os registos da pesquisa com os dados da pesquisa.
Resumindo o formulário de pesquisa quando abre não mostra dados, só quando coloca algum "dado" para filtro é que mostra...

Obs: Dividi em 3 BD porque o Access só aceita Banco de até 2GB. e o quase 5 milhordes de registros ocupam mais de 4GB, mesmo compactados, removendo os campos desnecessários...

Também testei buscar os dados direto do servidor que roda Hj Sql Server 2000. Porém como movimenta muitos dados, as vezes ele dá falha na chamada ODBC...

Olá Fabio,
Obrigado pelo retorno, dado o volume de dados então a melhor solução foi dividir.
Aguardamos se mais algum colega tem outra alternativa.
Abraço a todos

Olá amigo,

Sei que faz tempo que estava com a duvida, porém, estava procurando por outra coisa e acabei caindo aqui.

Nesse caso o PostgreSQL te da uma ajuda, pesquise sobre View e Materialized View, são consultas em sql que vc deixa rodando no back end e consegue visualizar no access como se fosse um tabela vinculada.

Hoje trabalho com o access somente front end e postgresql no back, roda muito liso, se o banco estiver hospedado na web pode ser que o tempo de resposta seja maior, mas ai é devido ao servidor aonde o banco está hospedado, tenho alguns clientes que utilizam local o banco e outros na web, ambos com tempo de resposta de 5 a 10ms.

Olá, tive o mesmo problema. Meu Banco de dados tem dados de + de 20 mil fundos de investimento e cada fundo conta com informes diários, totalizando mais de 18 milhões de registros. Os dados ficam no PostgreSQL online.

Minhas consultas demoravam 5 min para serem efetuadas. Resolvi apenas indexando o campo CNPJ do fundo que era o campo utilizado para unir as consultas.

De 5 minutos a consulta passou a ser executada em 4 segundos.

Imagino que se indexarem os campos certos as consultas de vocês passam a ser mais rápidas.

Campos relacionados e campos que servirão de base para pesquisa de registros merecem a consideração de serem indexados.

Índices nesses casos resolvem.

Olá a todos,

Ricardo Monteiro, obrigado pelo testemunho, o fórum agradece.

Abraço a todos e bons estudos