relatórios... como aumentar a performace???

[alaminojunior]

Como também faço uso deste tipo de função (para relatorios impressos, ou rotinas de edição), digo que especialmente nestes casos, dá na mesma. Para exibição em tela aí sim, use o ordscope() para te facilitar a vida.

[janio]

É como o Alanimo falou. Especificamente nesse caso acho que não fará diferença. Mas nas outras ocasiões sim.

O que o OrdScope faz é delimitar os dados no DBF que o sistema enxergará. Assim, vc pode ter um DBF com milhões de registros, mas somente aqueles que estiverem dentro da area delimitada serão considerados.

Jânio

[sygecom]

Luciaono,
Resumindo o ORDSCOPE() é um SET FILTER TO , porem mil vez mais rapido...realiza filtro sem lentidão.

Janio,
Se quise tenho uma rotina para visualização de TXT para HWGUI que pode enviar depois para emial, PDF e WORD, alias tenho mais de. Tenho uma aqui que usa o PREVIEW da HBPRINTER e manipula os CHR(15) , CHR(18) , eject e outros caracter especial...

[janio]

Grande Sygecom,

Agredeço, porém o problema continuará o mesmo, ou seja, só posso exibir o TXT depois que este estiver com todos os dados.

Preciso que vá GERANDO a medida que for EXIBINDO.

Jânio

[sygecom]

Janio, nesse caso nem o THREAD vai ajudar, o THREAD apenas vai deixar sua app livre em quanto roda a rotina do relatorio....ou seja como se fosse um segunda app rodando a rotina. mas o tempo vai ser o mesmo e só vai mostrar o TXT depois de criado. se quiser lhe mando uns exemplos de Mult-thread.

[Maligno]

Nada disso. O que o Janio quer é perfeitamente possível de se fazer, e só poderá ser feito com threads. Uma thread exibe parte do relatório que já está pronto no arquivo, em primeiro plano. Enquanto isso, outra thread continua montando o relatório em background. Só que será preciso montar um controle de eventos.

[edmarfrazao]

o que o Maligno disse seria a solução

uma theread gerando o relatorio no dbf
outra fazendo um browse no dbf.


o problema e fazer o codigo para isto

[Maligno]

Acho que botar DBF no meio é um artifício desnecessário. Um visualizador de TXT é algo muito simples e rápido de fazer. Inclusive, há código pronto em Clipper que pode ser aproveitado.

Quanto ao código envolvendo threads, é coisa realmente que dá um pouco de trabalho e até pode assustar a princípio, mas não é um bicho-papão. Agora, vale o ditado: "só se pode terminar depois de começar".

[janio]

se quiser lhe mando uns exemplos de Mult-thread.

Quero sim!

Jânio

[ederxc]

Se possivel ,cola aqui os exemplos , temgente acompanhando o tópico ....

[sygecom]

Nada disso. O que o Janio quer é perfeitamente possível de se fazer, e só poderá ser feito com threads. Uma thread exibe parte do relatório que já está pronto no arquivo, em primeiro plano. Enquanto isso, outra thread continua montando o relatório em background. Só que será preciso montar um controle de eventos.

O que eu quiz dizer é que mesmo assim não vai ser instanteneo com um DBF, conforme o exemplo do Janio, mesmo em thread separada ele levara o mesmo tempo para concluir todo o relatorio...

Eu faria o teste com thread como DBF, e iria mostrando em um tbrowse, e a cada movimento ou cada x segundos ia dando um refresh() até que o mesmo estaja completo...claro que usando um dbf temporario onde uma thread estaria com o dbf SHARED e a outra como READONLY.O problema vai ser os usuarios apresadinhos...que vão dando logo os page-down e não vai esta preenchido todo o tbrowse....

Vou ver se coloco um exemplo aqui no forum !!!

[Maligno]

O que eu quiz dizer é que mesmo assim não vai ser instanteneo com um DBF, conforme o exemplo do Janio, mesmo em thread separada ele levara o mesmo tempo para concluir todo o relatorio...

Entendi o que você quis dizer agora. O tempo para a geração total do relatório será o mesmo de antes. Mas não é essa a questão. Discordei do que você disse antes:

mas o tempo vai ser o mesmo e só vai mostrar o TXT depois de criado

Aí realmente está errado. A função das threads é justamente permitir a visualização do relatório enquanto ele estiver sendo gerado.

Ou, conforme a segunda idéia que o Janio lançou: gerar o relatório por demando. Em qualquer um dos casos é possível. Aliás, é possível até em Clipper mesmo.

Eu faria o teste com thread como DBF, e iria mostrando em um tbrowse, e a cada movimento ou cada x segundos ia dando um refresh() até que o mesmo estaja completo...

É uma idéia. Perfeitamente válida. Mas ainda acho que TXT é muito melhor e mais dinâmico. Mas isso vai do gosto de cada um.

[sygecom]

Pois, eu pensei no DBF por causa dos refresh() no tbrowse,nunca testei, mas visualizando um TXT pelo TBROWSE() tem como usar o refresh() ? se tiver como ai pode ser direto com TXT mesmo....

[Maligno]

Visualizar TXT pelo TBrowse implica em exportar o TXT para um DBF ou gerar o relatório diretamente pra DBF (um artifício que provavelmente ainda terá de ser implementado). Até funciona, mas é um procedimento que poderia ser dispensado. Além do que, manipular TXT é tão fácil que dá pra fazer um visualizador numa tarde. Mas tem coisa pronta por aí. É só recompilar. Desde que não tenha funções em C, como alguns que já vi.

Aliás, existe grátis no "The Oasis" uma LIB de tratamento de TXT que permite manipulá-lo como se fosse DBF (GOTO, SKIP, GOTOP, etc). É só recompilar pra XHarbour e montar o visualizador usando esse recurso. Eu fiz meu visualizador em Clipper mais ou menos desse jeito e ficou muito legal.

[sygecom]

Visualizar TXT pelo TBrowse implica em exportar o TXT para um DBF ou gerar o relatório diretamente pra DBF (um artifício que provavelmente ainda terá de ser implementado).

Negativo, olhe o exemplo desse tbrowse que visualiza arquivo TEXTO:
https://pctoledo.org/forum/viewtopic.php?t=3954