filter lento

[juniorcamilo]

amigos tenho um arquivo que é tanto para CLiente quanto para Fornecedor, blz, ai que vem, sabemos que em um estabelecimento comercial tende a ter mais Clientes do que Fornecedores, quando abro uma consulta em browse para ver um fornecedor usando um filter fica muito lenta a navegação neste browse pois o filter tende a pular (igual a ponteiro) muitos registro para achar outro codigo de fornecedor,, ex. para clientes uso 'C-00000' e para fornecedor uso 'F-00000'. tem algum modo de tornar o browse mais rapido?

[Maligno]

Por SET FILTER nem pensar. Só vejo duas soluções: separar os dados em dois arquivos. O custo disso pode ser alto, dependendo de quão intrincado for seu código. Como segunda opção, criar uma chave de índice que separe fornecedores e clientes. Neste caso, se você usa a LIB SIX, bastará montar um escopo. Sua navegação pelo browser ficaria excelente.

[]'s
Maligno
http://www.buzinello.com/prg

[Clipper]

Crie 2 indices para serem usados na consulta.

INDEX ON NOME FOR SUBSTR(CODIGO,1,1)="F" TO INDFOR
INDEX ON NOME FOR SUBSTR(CODIGO,1,1)="C" TO INDCLI

Até logo.

Marcelo

[rochinha]

Amiguinho

Tudo bem que costumamos ter arquivos que guardem pedidos de vendas e compras e com um flag o separemos ou contas a pagar e a receber num mesmo arquivo e saibamos que um não é o outro por um campo especifico.

Mas Clientes e Fornecedores é melhor voce separar os arquivos, pois deixando os juntos o que voce ganha? dor de cabeça é claro.

Separe seus arquivos tenha um para clientes, fornecedores, vendedores, compradores, transportadores, almozarifes, estoque, etc. Pois quando seu arquivo de clientes chegar aos 5000 e voce for tirar um relatório dos unicos 10 fornecedores na lista estará gastando memória, banda na rede e permitindo corrupção dos indices que controlam os clientes.

Pense sempre que cada tabela necessita ter suas rotinas proprias para cadastro, manutenção e listagem e mesmo que voce esteja fazendo isto para minimizar o codigo afim de liberar mais memória não será o caso quando o arquivo estiver grande de mais.

Separando voce terá maior controle quando precisar saber que o campo CGC do arquivo de clientes é controlado pelo CLIEN003.NTX e que o FORNE003 deve corresponder ao campo CGC no arquivo de fornecedores. A longo prazo é a melhor solução, pois o sistema não falha mas a memória....

[ederxc]

Para fornecedor um banco de dados e para clientes outo banco de dados

dessa forma que estamos falando fica mais facil vc fazer pesquisa no banco de dados eu nunca usei o "brownse " uso e DBEDIT() para visualiazar e e para pesqusar uso o dbseek() nunca tive problemas quanto a isso


NO banco fornecedor crie um codigo para fornecedor e no clientes tbm assim vc podera fazer pesquisas por codigo ou por nome que no caso cada banco tbm tera um nome ! Vai por mim vai ser muito mais facil do que vc usar o mesmo banco para ambos ! té+++



´o)

[rochinha]

Exemplo de estruturas:

Código: Selecionar todos

ESTRU_DBF := {}
   AADD( ESTRU_DBF, { "IDCODIGO", "N",  6, 0 } )
   AADD( ESTRU_DBF, { "NOME"        , "C", 45, 0 } )
   AADD( ESTRU_DBF, { "ENDERECO", "C",  45, 0 } )
   AADD( ESTRU_DBF, { "TELEFONE"  , "C",  14, 0 } )
   AADD( ESTRU_DBF, { "CIDADE"     , "C",  20, 0 } )
   AADD( ESTRU_DBF, { "ESTADO"    , "C",  2, 0 } )
   AADD( ESTRU_DBF, { "CEP"           , "C",  9, 0 } )
   AADD( ESTRU_DBF, { "OBS"          , "C",  255, 0 } )
   AADD( ESTRU_DBF, { "TIPO"         , "C",  1, 0 } )
   IF FILE("CLIENTES.DBF")
       DBCREATE( "CLIENTES", ESTRU_DBF )
   ENDIF
   IF FILE("FORNEC.DBF")
       DBCREATE( "FORNEC", ESTRU_DBF )
   ENDIF
   IF FILE("VENDEDOR.DBF")
       DBCREATE( "VENCEDOR", ESTRU_DBF )
   ENDIF

No exemplo acima crio os arquivos CLIENTES, FORNECedores e VENDEDORes usando uma mesma estrutura.

Na verdade só saberei qual seu conteudo olhando o nome do arquivo.

No momento de indexar eu uso(terminologia NTX):

USE CLIENTES
INDEX ON IDCODIGO TO CLIEN001

USE FORNEC
INDEX ON IDCODIGO TO FORNE001

USE VENDEDOR
INDEX ON IDCODIGO TO VENDE001

10 anos depois saberei que CLIEN001, FORNE001 e VENDE001 devem ser indices de um campo de mesmo nome e teor. Não importa se a estrutura recebeu novos e diferentes campos depois, mas os básicos devem ter uma mesma semelhança afim de facilitar a manutenção posterior.

Veja também que a função que cria os arquivos é pequena e se tiver algumas diferenças de campos basta recortar, colar e alterar e criar outro trecho de codigo.

Em relação ao DBedit e Browse os dois tem as mesmas funções com diferença na programação enquanto o DBEdit pode ser manipulado externamente o Browse pode ser reestruturado, mas em suma os dois fazem a mesma coisa, dão browse nos dados, ou seja, browse seria um verbo na lingua informatiquez, tipo:

eu dou um browse,
tu browseas,
eles browseam

Eu zipo,
tuzipas,
eles zipam

Eu mesmo nunca gostei do browse em Clipper, adorava o DBEdit, mas ao passar para Fivewin, não o encontrei e dei de cara com trocentas versões de Browses, mas um ano depois ja sabia como domina-los.

[Maligno]

É sempre bom lembrar que fornecedor pode ser cliente e cliente pode ser fornecedor. E há muita gente que defende o uso de um único arquivo de dados para ambos (não só em C/S mas também em acesso local, caso do DBF). Não se pode dizer que isso está errado, nem que é pior ou melhor. Até porque, cada um tem lá suas conveniências. Se o sistema for bem estruturado, dificilmente se perceberá qualquer lentidão. Pra isso existe a indexação. Com SIX fica mais fácil ainda.

[]'s
Maligno
http://www.buzinello.com/prg

[juniorcamilo]

É sempre bom lembrar que fornecedor pode ser cliente e cliente pode ser fornecedor. E há muita gente que defende o uso de um único arquivo de dados para ambos (não só em C/S mas também em acesso local, caso do DBF). Não se pode dizer que isso está errado, nem que é pior ou melhor. Até porque, cada um tem lá suas conveniências. Se o sistema for bem estruturado, dificilmente se perceberá qualquer lentidão. Pra isso existe a indexação. Com SIX fica mais fácil ainda.

[]'s
Maligno
http://www.buzinello.com/prg

todas as opinioes e ajuda postada aqui, sao inteiramente uteis, e sérias mas eu me enquadro na ajuda e ponto de vista do maligno. Maligno gostaria de saber mais sobre o q vc disse SIX. me explica melhor.. valeu

[Maligno]

gostaria de saber mais sobre o q vc disse SIX. me explica melhor..

A LIB SIX contém uma série de RDDs para substituir o RDD default do Clipper (NTX), o que permite o uso de índices compostos e compactados. O que eu utilizo é o SIXNSX, que é muito menor que um NTX comum e ainda me permite ter diversas chaves de indexação em um mesmo arquivo. Sendo compactado, sua velocidade de indexação é muito maior, o que faz aumentar também a velocidade de acesso.
Além disso, com a estrutura da LIB, você tem diversas funções de apoio, dentre as quais, destado a sx_SetScope(), que é justamente a que poderá ajudá-lo a criar uma espécie de arquivo dentro do arquivo de dados.
Imagine um arquivo com 100.000 registros, contendo fornecedores e clientes. Com uma letra que permite a distinção entre um e outro, você poderia montar o escopo que limita a visão do programa para que ele apenas "enxergue" fornecedores:

sx_SetScope(0,"F") // marquei o topo
sx_SetScope(1,"F") // marquei o final

Assim se forma este "arquivo" virtual, tendo apenas os fornecedores. Dentro deste "arquivo", bem menor que o arquivo físico, você poderá manipular seus dados com mais tranqüilidade, podendo inclusive montar um SET FILTER para refinar mais ainda sua pesquisa.

As possibilidades desta LIB são bem maiores que isso, claro. Mas não é possível entrar em detalhes numa mensagem de fórum. Existem vários tópicos abordando esse assunto. Aconselho você a instalar a LIB e rodar o demo, que é bem ilustrativo. E, claro, LER a documentação ajuda muito mais.

Download da SIX: clique aqui.

[]'s
Maligno
http://www.buzinello.com/prg

[juniorcamilo]

Obrigado Maligno....