Exibir % enquanto indexa

[Anderson J. Freitas]

Baixei o arquivo do dudu_xbase no caminho abaixo

http://br.share.geocities.com/dudu_xbase/exemplo.zip

dele extraí a função para exibir a porcentagem enquanto indexa, porém percebi q sem a função demora 27s. Com a função demora 2min. Diante disso pergunto :

1 - É possível remontar a função de forma que exiba a porcentagem sem aumentar tanto o tempo de indexação ?
2 - Depois do TAG na indexação utilizando NSX, posso usar letras ao invés de números ?

Grato

#include 'sixnsx.ch'
rddsetdefautl("SIXNSX")
ferase("cepdu.nsx")
use cepdu new
index on LOGRADOURO+BAIRRO tag 3 eval Progress("NSX RUA 1/1",16)

Static Function progress (cString,nLin)
local cComplete
Local nPorc := Int(RecNo()/LastRec()*100)
Set Cursor Off
setcursor(0)
if recno() = 1
@ nlin,12 Say repl("_",50) Color "W/W*"
endif
@ nlin,12 Say Replicate("_",int(nPorc/2)) Color "R+/W"
@ nlin,63 Say nPorc Picture "999" Color "W+/r"
@ nlin,68 Say nPorc Picture " %" Color "W+/r"
Set Cursor On
cComplete := alltrim(transform(((recno()/lastrec())*100),"999.99"))
setpos(nlin-1,12); dispout("Progresso »» "+cString+" - "+cComplete+" %","g/r
return ( .t. )

[Dudu_XBase]

Boa Noite Anderson !


Soluções:


1.
Altere essa parte do código abaixo ele executará a função a cada lastrec()/100, por exemplo vc tem um dbf com 30.000 registros divido por 100 assim a cada 300 registros ele executará a função progress, diminuindo consideravelmente o tempo de sua indexação.

Código: Selecionar todos

  index on DUDU tag 3 eval Progress("dudu 1/1",16) every lastrec()/100
  

2.
Sim vc pode usar letras para identificar as tags.

index on LOGRADOURO+bairro tag logbai

Para navegar entre as tag com nome use a função SX_SetTag(), fununcia ki nem dbsetorder() para vc posicionar o indice.

sx_SetTag("logbai")



Mais informações :

// sobre a função SX_SetTag()
http://www.clipx.net/ng/six3/ng377d5.php

// Sobre o comando Index on no Six RDD
http://www.clipx.net/ng/six3/ng47721.php

[Maligno]

Não me ative ao código propriamente. Mas veja: a indexação será tão lenta quanto mais código tiver de ser executado pela função de acompanhamento do progresso. Não me refiro apenas ao tamanho e à qualidade do código da função. Também à quantidade de repetições.

1 - É possível remontar a função de forma que exiba a porcentagem sem aumentar tanto o tempo de indexação?

Sua função de indicação de progresso está sendo chamada a cada leitura de registro, o que é desnecessário. Para evitar isso existe a cláusula EVERY (leia o NG), que você não usou, e que serve para limitar a avaliação do bloco configurado por meio da cláusula EVAL. Sem um valor em EVERY a velocidade cairá tanto quanto maior for a base de dados. Portanto, é preciso fazer um balanceamento, onde se deve levar em conta a quantidade total de registros e, se houver uma barra de progresso, por exemplo, a largura desta barra. Supondo que essa barra tenha 30 caracteres de largura, você deve limitar a execução da função em 30 vezes, calculando o valor ideal para a cláusula EVERY. Assim, num arquivo com 1.000.000 de registros, a função deverá ser executada apenas 30 vezes. Executá-la mais de 30 vezes seria perda de tempo, pois nada mudaria esteticamente.
Em suma: o tipo da animação (percentual, barra, etc) do progresso deve ser levada em conta para limitar a execução da função.

2 - Depois do TAG na indexação utilizando NSX, posso usar letras ao invés de números?

Pode.


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

[Dudu_XBase]

:)Pos Duas respostas e quase simultâneas.

[marbio]

Boa Noite!!!,,

Nao e nunhuma funcao o que funcao e da para o gasto.

t+





L=8
L1=15 // Arquivo
L2=4
L3=24
L4=27 // Indice 1
L5=39 // Indice 2
l6=51 // Indice 3

@06,07 say 'N. Reg.'
@06,l1 say 'Arquivo'
@06,l4 say 'Indice 1'
@06,l5 say 'Indice 2'
setcolor(cor2)

close all

************************* CLIENTE **************************

if netuse("cliente",.t.,10)
@ L, 6 say Transform(LastRec(), "999,999")
@ L, l1 say "CLIENTE"
@ L, l4 say " "
ordcondset(Nil, Nil, Nil, Nil, {|| fntxprog(1)}, Nil, RecNo(), ;
Nil, Nil, Nil, Nil)
@ L, l4 say 'CLI001.NTX'
ordcreate("CLI001", Nil, "codigo", {|| codigo}, Nil)
@ L, l5 say 'CLI002.NTX'
ordcondset(Nil, Nil, Nil, Nil, {|| fntxprog(2)}, Nil, RecNo(), ;
Nil, Nil, Nil, Nil)
ordcreate("CLI002", Nil, "nome", {|| nome}, Nil)
L++
else
* msgar()
return
endif



***************************************
function FNTXPROG(Arg1)
local Local1
Local1:= RecNo() / LastRec() * 100
* @ 23, 19 say Str(Arg1, 2, 0)
* @ L, 61 say Transform(RecNo(), "@E 99,999,999")
@ l, 70 say Transform(Local1, "@E 999")+ "%"
return .T.

[Maligno]

ordcondset(Nil, Nil, Nil, Nil, {|| fntxprog(1)}, Nil, RecNo(),Nil, Nil, Nil, Nil)

Se o argumento é Nil, você não precisa mencionar. Basta deixá-lo em branco, que o efeito é o mesmo.

Cada qual tem sua forma de trabalhar, mas acredito que você está desperdiçando uma boa qualidade do Clipper: os comandos. Ao invés de funções como essa, que exige muitos parâmetros, você poderia aproveitar o comando que já existe.

Os comandos, além de mais amigáveis e intuitivos, ajudam a melhorar a legibilidade, o que facilita enormemente a manutenção, que por sua vez, reduziria sua carga de trabalho, deixando-o livre para pensar em coisas que realmente valem a pena.
Neste código você saberia dizer, de memória, o que representa o sexto parâmetro? Imagino que não.
Já pensou o que aconteceria se colocasse uma vírgula a mais ou a menos? Você acabaria empacado num problema facilmente evitável. E dependendo da função e do argumento, você nem desconfiaria qual função seria a culpada. Poderia levar horas para descobrir o erro.

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

[marbio]

Bom dia !!!!


Aqui é um lugar para ajudar, e criticas construtivas. Para ajudar os amigos com trabalham com CLIPPER, se a função não serve, critique, nas melhores intenções, com Ex: claro para os outros PROGRAMADOR. Que não fique boiando.
Ao invés de ficar criticando, nos temos que AJUDAR, aqueles que não sabe..............


Desde ja agradeco sua atencao!!!!!!!!!!!

[Dudu_XBase]

Marbio boa Tarde !
O Maligno em nenhum momento do seu post criticou a sua função e sim fez uma critica construtiva, lhe informando a falta de necessidade de vc usar a claúsula nil e sobre tomar cuidado com os parâmetros de cada comando.
Vc deve ter ficado ofendido sei lá, não estou tomando as dores, nem defendendo ninguém, só estou expondo minha opinião.

:xau

[marbio]

Eu concordo com vc..............



:*

[ABeltrani]

Bom dia pessoal ! Fazia tempo que não entrava aqui. Pintou uma dúvida. Recentemente, agora não me lembro onde lí, ouvi dizer que o uso do eval no index on aumenta o tamanho do arquivo de indice. Fiz o teste e constatei que realmente isso acontece. Alguem sabe dizer algo a respeito ?

Grato

Ademir.

[Pablo César]

Eu não tenho certeza disso e isso que você afirma é em NTX ou outro RDD ?. Caberia comparar o mesmo arquivo de índice um com o uso do EVAL e outro sem.

[ABeltrani]

Boa tarde !

O RDD é o NTX. Já fiz os testes com e sem eval.

[Pablo César]

Fiz testes e de fato ocorre diferença de tamanho nos NTXs compilado com Clipper 5.2E noentanto não ocorre o mesmo compilado em xHarbour. Isto é, a indexação com EVAL ou sem o tamanho dos NTXS permanece iguais. Muito esquicito, não é ?. Embora haja essa diferença de tamanho, na utilização dos índices aparentemente não interfere em nada.

Só para fins estatisticos:

Nº registros do DBF: 7929
Arquivo NTX em xHarbour com EVAL: 510.976
Arquivo NTX em xHarbour sem EVAL: 510.976
Arquivo NTX em Clipper com EVAL...: 985.088
Arquivo NTX em Clipper com EVAL...: 520.192

As caracterisiticas físicas do arquivo NTX do Clipper (com e sem EVAL) são diferentes. Me refiro a instrução binaria antes dos dados.

[ABeltrani]

Boa noite !

Lí tambem que o fato do tamanho do indice ser diferente não interfere no funcionamento do indice. Pelo que lí, parece que o Clipper com o eval, na hora de criar o arquivo NTX "pula" uma etapa que me parece ser a de compactação do indice que é feita normalmente sem o uso do eval. Por isso perguntei se alguem sabia mais alguma coisa a respeito.

[Pablo César]

Será que isto acontence tabém com outros RDDs ? O bom que em xHarbour não acontece isso, além de ser mais rápido o processo de indexação. Por isso que eu mantenho o módulo de indexação em 32 Bits.