|
|
|
|
|
Dicas
|
|
Visual Basic (Crystal Reports)
|
|
|
Título da Dica: Como otimizar o processamento dos relatórios?
|
|
|
|
Postada em 17/3/2004 por ~Ð@®£@Ñ
Muitas vezes um relatório pode ser executado em menor tempo do que aquele tempo que ele tem atualmente para o término de seu processamento. O tempo de execução de um relatório varia de acordo com o método de acesso aos dados (ODBC/Nativo), com a complexidade da consulta SQL executada, com a capacidade de processamento da máquina, etc. Porém há algumas dicas úteis para otimizar o seu processamento:
- verificar se as seleções presentes no menu Report | Select Expert, estão sendo refletidas na consulta SQL do relatório (menu Database | Show SQL Query). Caso estejam sendo utilizadas fórmulas que são processadas localmente, a performance do relatório pode cair, uma vez que a consulta refletida no menu Database | Show SQL Query é processada no lado do servidor. Se isto ocorrer, estude a possibilidade de utilizar expressões SQL ao invés de fórmulas do Crystal, através do menu Insert|SQL Expression (a partir da versão 8 para bancos de dados SQL). Verificar inclusive, o uso de If-then-Else no Select, pois força a seleção a ser feita localmente. - uma vez que o relatório possa ter a linha de detalhes escondida e possuir sumários que não sejam do tipo Distinct Count, verifique se marcando a opção Perform Group On Server no menu File | Report Options, a parte GROUP BY é montada do lado do servidor (menu Database | Show SQL Query). - caso existam subrelatórios no relatório, verifique a possibilidade de deixá-los "On-demand" - sempre que possível, em relatórios de muitas páginas, não utilize o contador geral de páginas, o qual obriga o Crystal a processar todas as páginas ao invés de apenas a primeira e as que forem sendo solicitadas (recurso Page-On-Demand). - se você estiver usando objetos do texto, evite introduzir campos da base de dados ou da fórmula dentro deles para fazer o relatório funcionar mais rapidamente. - sempre que possível, utilize conexão nativa ao banco de dados, ao invés de ODBC, pois o ODBC requer mais "layers" para acessar os dados.
|
|
|
|
|