Relatório demorado

[Poka]

Bom dia

Ref. ao relatório demorado, a empresa colocou o Windows server. Agora tá um foguete.

Poka

[rubens]

Bom dia Poka...
Então mesmo com Firebird fica lento?
Sei que com o server +TS é muito rápido mesmo com set filter to ..
Agora imaginava que com firebird/mysql etc fica igual ao server...

Rubens

[asimoes]

Relatório demorado pode ser arquivos temporários para gerar o relatório, eu trocaria o HDD por SSD

[JoséQuintas]

Relatório demorado pode ser arquivos temporários para gerar o relatório, eu trocaria o HDD por SSD

Infelizmente não é isso.
Se demora pra puxar dados da rede, tanto faz SSD ou não.

O ideal é usar o SQL como exemplo:

- Índices não são pra trazer tudo prontinho, são pra agilizar a pesquisa. Considere isso pra DBF: a prioridade pra criação de índices é agilização de pesquisa

- Criar temporário é bom pra evitar processamento de rede DURANTE O USO.

supondo que seja relatório do dia 1 em ordem alfabética.... melhor o índice pelo dia 1, e criar temporário primeiro, e só depois trabalhar pra colocar em ordem alfabética, porque aí o processamento é local velocidade máxima

É isso que o SQL faz, mas processando no servidor.

[JoséQuintas]

Acrescentando....

Muitas vezes o programador usa array pra agilizar as coisas.
Não é o array que deixa mais rápido, é o processamento local.

Usando o exemplo anterior... trás o dia 1 e trabalha com ele.
Se faz isso com dbf ou array, de qualquer jeito vai ser muito mais rápido do que direto na base em rede.
Vai depender muito do tipo de processamento, mas tem casos onde usando array pode ser até mais demorado

Simples:
Em DBF local vai ser um registro por vez, um SEEK posicionando.
Em array, pode precisar pesquisar todo array pra encontrar alguma coisa.
Então... tem casos onde o melhor é dbf temporário mesmo, e não array.

Esse acima é um bom exemplo: não é o índice em ordem alfabética que vai deixar mais rápido, e sim o índice por ordem de data.
Em ordem de data vai processar menos registros, somente aquela data, então... cria temporário com eles e depois trata de colocar em ordem alfabética.
Já se tiver índice em ordem alfabética... vai ter que processar todos os registros pra retirar uma data, o que demora muuuito mais.

No final... o SQL acaba usando o que muitos programadores esquecem de usar.
E o mesmo que agiliza DBF também vai agilizar SQL, então pode ser bom ir praticando com DBF.
Ou... olhar como o SQL faz, pra fazer igual....

E isso tudo é interessante, é como sempre digo: ficar craque no básico, tira proveito em qualquer coisa avançada.
Sabendo melhorar no dbf, também vai saber melhorar no SQL criando índices corretos.

[Poka]

Olá

Rubens Disse

Então mesmo com Firebird fica lento?

Não. Esse está com DBF.

Sobre o Firebird já fiz teste aqui no meu computador e a velocidade do terminal fica praticamente a mesma. Estou mudando esse sistema para o Firebird. Até abandonar de vez o DBF.

É que a coisa é demorada mesmo. Refazer um sistema inteiro não é fácil.
Só pra informação, já fiz um teste aqui no meu computador com Firebird selecionando SILVA por exemplo em um arquivo com um milhão de registros.
Demorou 15 segundos (muito tempo) mas o meu computador é muito antigo. Levei num cliente que tem uma rede com computador bem melhor, demorou 5 segundos. Achei muito bom. imagina fazer um set filter com dbf num arquivo desses.

Poka

[Fernando queiroz]

Falando em temporário , to usando o DBF em memoria e me deparei com o seguinte problema:

se dois usuários em maquinas diferentes criar o arquivo em memoria com o mesmo nome acontece o
erro 32 , ai fica a duvida , se o arquivo é criado em memoria e cada um na sua maquina não deveria acontecer esse erro

solução foi criar arquivo na memoria com nome diferentes, rosolveu o BO :% :% :%

[JoséQuintas]

Falando em temporário , to usando o DBF em memoria e me deparei com o seguinte problema:se dois usuários em maquinas diferentes criar o arquivo em memoria com o mesmo nome acontece oerro 32 , ai fica a duvida , se o arquivo é criado em memoria e cada um na sua maquina não deveria acontecer esse erro

Conclusão: não está usando dbf em memória !!!!

Uma coisa importantíiiiiiissima sobre dbf em memória é: precisa adicional na compilação, se esquecer disso, já era o temporário em memória, acaba sendo em disco mesmo !!!

Pior: MEM:arquivo, dependendo da versão do Windows, isso cria arquivo em um local oculto, sem qualquer acesso externo. Pode encher o HD sem enxergar de jeito nenhum aonde estão os arquivos escondidos. Tive esse problema logo no começo ao usar nome de arquivo com dois pontos, não lembro se foi no NET:arquivo ou outro.

Conclusão: melhor não inventar, o básico sempre funcionou e sempre vai funcionar

Ou, como eu disse antes, siga os exemplos: O que o Windows e os programas mais fazem é criar arquivo temporário. Com certeza existe motivo pra isso. Se usar só memória fosse bom, nem o Windows usaria arquivo temporário.