Sistema de Busca

[Manoel Zancheta]

Olá.

Utilizo um sistema de busca aonde faço a digitação num Edit e pesquiso num DBGrid com lopartialkey. Está funcionando bem, exceto pelo fato de ficar lento a carga no DBGrid para as tabelas maiores pois já carrego todos os registro da tabela de uma vez. Existe alguma forma de carregar parcialmente os registros e ser atualizado conforme houver necessidade?

Grato!

Editado Dezembro 8, 2008 por Manoel Zancheta

[Jhonas]

Utilizo um sistema de busca aonde faço a digitação num Edit e pesquiso num DBGrid com lopartialkey. Está funcionando bem, exceto pelo fato de ficar lento a carga no DBGrid para as tabelas maiores pois já carrego todos os registro da tabela de uma vez. Existe alguma forma de carregar parcialmente os registros e ser atualizado conforme houver necessidade?

Existe sim .... basta utilizar a instrução select para fazer a pesquisa

exemplo:

http://scriptbrasil.com.br/forum/index.php...st&p=520800

OBS: Além de ficar rapido por trazer menos registros, voce pode atualizar somente os registros escolhidos

abraço

[Manoel Zancheta]

Olá.

Jhonas, meu problema não é este.

Pense o seguinte, tenho um cadastro de produtos com 20.000 itens. Hoje eu carrego o DBGrid com todos os 20.000 registros (esta "carga" fica lenta em máquinas modestas), porém depois a minha pesquisa fica rápida pois está tudo na memória, então se for pro início do grid, final, rolar o grid com setas, com page up e down, fica bala. Porém, o problema é que o usuário faz várias buscas por nome seguidas e todas vez tem esta carga que é demorada. Existe algo no componente que limite a carga no mesmo parcialmente mesmo que o select tenha sido completo?

[Jhonas]

Jhonas, meu problema não é este.

Pense o seguinte, tenho um cadastro de produtos com 20.000 itens. Hoje eu carrego o DBGrid com todos os 20.000 registros (esta "carga" fica lenta em máquinas modestas), porém depois a minha pesquisa fica rápida pois está tudo na memória, então se for pro início do grid, final, rolar o grid com setas, com page up e down, fica bala. Porém, o problema é que o usuário faz várias buscas por nome seguidas e todas vez tem esta carga que é demorada. Existe algo no componente que limite a carga no mesmo parcialmente mesmo que o select tenha sido completo?

Manoel .. tenho um cadastro de produtos com aproximandamente 90.000 itens e cada registro tem 18 campos... preferi usar o componente TTable com uso de indices

TCadProd1.IndexDefs.Clear;
         TCadProd1.IndexName := 'CODPROX';  // nome do indice para o código do produto
         TCadProd1.IndexDefs.Update;

a carga dos registros ( 90.000 )... leva 1 segundo para trazer os registros para o dbgrid... e para pesquisa usei o comando:

TCadProd1.FindNearest([trim(Edit1.Text)]);

este tempo está em torno de 100 milisegundos

Desta maneira o seu usuário pode escolher qualquer opção de pesquisa, desde que esta opção esteja usando um indice correspondente ao campo.

abraço

[Manoel Zancheta]

Jhonas, meu problema não é este.

Pense o seguinte, tenho um cadastro de produtos com 20.000 itens. Hoje eu carrego o DBGrid com todos os 20.000 registros (esta "carga" fica lenta em máquinas modestas), porém depois a minha pesquisa fica rápida pois está tudo na memória, então se for pro início do grid, final, rolar o grid com setas, com page up e down, fica bala. Porém, o problema é que o usuário faz várias buscas por nome seguidas e todas vez tem esta carga que é demorada. Existe algo no componente que limite a carga no mesmo parcialmente mesmo que o select tenha sido completo?

Manoel .. tenho um cadastro de produtos com aproximandamente 90.000 itens e cada registro tem 18 campos... preferi usar o componente TTable com uso de indices

TCadProd1.IndexDefs.Clear;
         TCadProd1.IndexName := 'CODPROX';  // nome do indice para o código do produto
         TCadProd1.IndexDefs.Update;

a carga dos registros ( 90.000 )... leva 1 segundo para trazer os registros para o dbgrid... e para pesquisa usei o comando:

TCadProd1.FindNearest([trim(Edit1.Text)]);

este tempo está em torno de 100 milisegundos

Desta maneira o seu usuário pode escolher qualquer opção de pesquisa, desde que esta opção esteja usando um indice correspondente ao campo.

abraço

Olá.

Em qual configuração de hardware você obteve esta performance?

[Jhonas]

Em qual configuração de hardware você obteve esta performance?

Configuração do meu micro

Sistema:

Microsoft Windows XP

Professional

Versão 2002

Service Pack 2

Computador:

Processador AMD level 6 Rev. 8.1 (x86 Family 6 Model 8 Stepping 1)

1.79 GHz, 256 MB de RAM

abraço

[Manoel Zancheta]

Ok Jhonas, obrigado.

Vou fazer um teste hoje.

[Micheus]

Manoel .. tenho um cadastro de produtos com aproximandamente 90.000 itens e cada registro tem 18 campos... preferi usar o componente TTable com uso de indices

...

Desta maneira o seu usuário pode escolher qualquer opção de pesquisa, desde que esta opção esteja usando um indice correspondente ao campo.

Bem observado Jhonas. A definição de índices para campos de consulta, acelera e muito as buscas.

Manoel Zancheta, você não mencionou o banco de dados que está utilizando. No caso de banco de dados como SQLServer (o qual já utilizei, com TTable), o simples fato de definir na propriedade FieldsIndex o nome do campo a ser ordenado, resulta na criação de um índice temporário (no caso de que este ainda não exista). Já no caso de tabelas Paradox, o índice tem que ser criado mesmo.

Abraços

[Manoel Zancheta]

Manoel .. tenho um cadastro de produtos com aproximandamente 90.000 itens e cada registro tem 18 campos... preferi usar o componente TTable com uso de indices

...

Desta maneira o seu usuário pode escolher qualquer opção de pesquisa, desde que esta opção esteja usando um indice correspondente ao campo.

Bem observado Jhonas. A definição de índices para campos de consulta, acelera e muito as buscas.

Manoel Zancheta, você não mencionou o banco de dados que está utilizando. No caso de banco de dados como SQLServer (o qual já utilizei, com TTable), o simples fato de definir na propriedade FieldsIndex o nome do campo a ser ordenado, resulta na criação de um índice temporário (no caso de que este ainda não exista). Já no caso de tabelas Paradox, o índice tem que ser criado mesmo.

Abraços

Opa, foi mal:

- Delphi 6

- FireBird 1.5

- IBX

Um abraço!