AJUDA COM CRYSTAL REPORT
vb6 + mysql + crystal 11
seguinte, tudo toda legal. mas esta lento para gerar relatorios, mesmo quando uso filtros...
dentro do proprio crystal report, quando clico para atualizar o relatorio para ver o resultado, ele fica escrito na barra de status: "accessing database..."
e ai fica, chega a travar a makina...
alguem pode me mostrar como fazer a conexão via vb, e dentro do crystal como conectar ao banco de dados, para poder ver se estou errado...
um exemplo dentro do vb para chamar o relatorio...
eu estou usando selectionformula dentro do vb para passar os filtros da pesquisa... mas fica muito lento e demora muito, se o bd tiver umas 1000 linhas já vira uma carroça para poder gerar o relatorio... e quando esta muito grande,,... nao sai o relatorio,trava...
obrigado para quem puder me ajudar...
seguinte, tudo toda legal. mas esta lento para gerar relatorios, mesmo quando uso filtros...
dentro do proprio crystal report, quando clico para atualizar o relatorio para ver o resultado, ele fica escrito na barra de status: "accessing database..."
e ai fica, chega a travar a makina...
alguem pode me mostrar como fazer a conexão via vb, e dentro do crystal como conectar ao banco de dados, para poder ver se estou errado...
um exemplo dentro do vb para chamar o relatorio...
eu estou usando selectionformula dentro do vb para passar os filtros da pesquisa... mas fica muito lento e demora muito, se o bd tiver umas 1000 linhas já vira uma carroça para poder gerar o relatorio... e quando esta muito grande,,... nao sai o relatorio,trava...
obrigado para quem puder me ajudar...
Esta lentidão tanto no VB quanto no Crystal já exime o VB da culpa.
O problema está entre seu DataBase e o Crystal.
Na maior parte das vezes lentidão em preocessos com BD ocorrem poe estarmos percorrendo e Juntando tabelas sem uma utilização racional dos chamados Indexes das tabelas.
Index é a grosso modo a ordenação fÃsica dos registros na tabela.
Por Exemplo, se tivermos nossa tabela cliente ordenada pelo campo id_cliente o SGDB poderá utilizar um processo chamado Procura Binária que otimiza em algumas centenas ou milhares de vezes a consulta por table Scan ( Procura Linear )
Imaginemos ter 1000 clientes e 5000 telefones linkados a eles, se a tabela telefone tiver um indice que ordene (ou mapeie) id_cliente dentro dela não será necessário percorrer os 5000 (ou milhões) de registros ... um exemplo que usa no caso apenas 2 tabelas.
O inconveniente deste processo é que a inclusão e exclusão de registros obriga a reordenação da tabela na hora de sua execução, ou seja , fica lento.
Um teste para verificar se não seria este o caso seria executar a consulta que o Crystal faz diretamente no MySQL e verificar se o desempenho ainda é sofrivel, se for é exatamente o que eu falei, ae um DBA local seria recomendável.
O problema está entre seu DataBase e o Crystal.
Na maior parte das vezes lentidão em preocessos com BD ocorrem poe estarmos percorrendo e Juntando tabelas sem uma utilização racional dos chamados Indexes das tabelas.
Index é a grosso modo a ordenação fÃsica dos registros na tabela.
Por Exemplo, se tivermos nossa tabela cliente ordenada pelo campo id_cliente o SGDB poderá utilizar um processo chamado Procura Binária que otimiza em algumas centenas ou milhares de vezes a consulta por table Scan ( Procura Linear )
Imaginemos ter 1000 clientes e 5000 telefones linkados a eles, se a tabela telefone tiver um indice que ordene (ou mapeie) id_cliente dentro dela não será necessário percorrer os 5000 (ou milhões) de registros ... um exemplo que usa no caso apenas 2 tabelas.
O inconveniente deste processo é que a inclusão e exclusão de registros obriga a reordenação da tabela na hora de sua execução, ou seja , fica lento.
Um teste para verificar se não seria este o caso seria executar a consulta que o Crystal faz diretamente no MySQL e verificar se o desempenho ainda é sofrivel, se for é exatamente o que eu falei, ae um DBA local seria recomendável.
Pois então rapaz, uso muito as ferramentas que vc indicou e gostaria de saber a natureza do problema e a eventual solução estar precavido.
Tópico encerrado , respostas não são mais permitidas