select X alias

[Ademir]

Boa noite a todos !

Dados os dois codigos abaixo:

Código: Selecionar todos

select arq1
vcodigo=codigo
select arq2
if dbseek(vcodigo)
   do whil !eof()
       if codigo2 > vcodigo
          exit
       endi
       vdata2=data2
        sele arq3
        appe blan
        repl data3 with vdata2
        sele arq2
        skip
    endd
endi

select arq2
if dbseek(arq1->codigo)
   do whil !eof()
      if codigo2 > arq1->codigo
         exit
      endi
      sele arq3
      appe blan
      repl data3 with arq2->data2
      sele arq2
      skip
   endd
endi

Pergunto:

1) Os dois fazem a mesma coisa ?
2) O quê pode ser melhorado no segundo codigo ?

Um abraço a todos.

[vagucs]

O resultado é o mesmo, mas programadores mais modernos nem usam o select mais, tudo fica referenciado, fica assim seu codigo.

Código: Selecionar todos

if arq2->(dbseek(arq1->codigo) )
   do whil !arq2->(eof() )
      if arq2->codigo2 > arq1->codigo 
         exit 
      endi 
      arq3->(dbappend())
      arq3->data3=arq2->data2 
      arq2->(dbskip ())
   endd 
endi 

mais reduzido e otimizado.

[Maligno]

Se for uma grande quantidade de operações em cima de uma área só ou se for uma repetição com muitas iterações, pode ser bem mais econômico e rápido usar SELECT. Portanto, é perfeitamente compreensível que os programadores, modernos ou não, continuem usando esse comando.

A referência à uma área, internamente, faz a área ser selecionada, de qualquer maneira. Ao fim, a área anterior é selecionada. No código acima, se poderia manter a área Arq2 como a selecionada e fazer apenas uma referência às áreas Arq1 e Arq3. Seria mais econômico e o código ficaria mais rápido. Se pouco ou muito, não sei. Depende da quantidade de iterações na malha.

Acho que ficaria melhor assim:

Código: Selecionar todos

select Arq2
if dbSeek(Arq1->CODIGO)
   while !EoF()
      if CODIGO2 > Arq1->CODIGO
         exit 
      end 
      Arq3->(dbAppend()) 
      Arq3->DATA3 := DATA2 
      dbSkip()
   end
end

[Ademir]

Bom dia a todos !

Perguntas:

Se em vez de selecionar a area, eu apenas fazer referencia a ela, o processamento ficará mais lento ?

Eu costumo dependendo do caso, bloquear o arquivo antes de dar append. No caso da função dbappend() devo usá-la assim dbappend(.f.) ou assim dbappend(.t.)

Desde já agradeço.

Um abraço.

[Maligno]

Se em vez de selecionar a area, eu apenas fazer referencia a ela, o processamento ficará mais lento ?

Analise da seguinte forma: um código como Arq->(dbSkip()) faz o quê? Internamente ele seleciona a área onde a operação deve ser realizada, efetua a operação e depois retorna à área anterior. Não pode ser diferente disso. Portanto, referências desse tipo, se em excesso, consomem mais código, o que pode tornar o programa mais lento. Se repetido n vezes, numa malha, mais lento ainda.

No caso da função dbappend() devo usá-la assim dbappend(.f.) ou assim dbappend(.t.)

Mas o dbAppend não tem parâmetro nenhum no clipper 5.2. Se tiver, só se for na versão 5.3.

[Eolo]

Moderno ou não, eu ainda acho que, no "geral", cada programador pode e deve trabalhar do modo que achar mais conveniente (desde que funcione).

Meu ponto é que não adianta eu copiar do Fulano um código tecnicamente perfeito, cheio por exemplo de code blocks, se eu não sei mexer com code blocks e não vou conseguir, amanhã, fazer sozinho aquela alteração que meu cliente pediu... O code block, ao final, vai é me ferrar.

Quanto a performance, também é discutível: em determinados sistemas, concordo que um nanosegundo pode ser muito. Mas numa aplicação comercial comum, numa rede pequena, que diferença um segundo vai fazer pro cliente? Alguém já flagrou um cliente com um cronômetro na mão?

[Ademir]

Na versão 5.3 ele tem:

Se for .t. ele cancela todos os bloqueios de registro pendentes.

Se for .f. todos os bloqueios são mantidos.

O default é .t.

A duvida é:

Em acesso multiusuario, antes de criar um novo registro eu bloqueio o arquivo, gravo o registro e desbloqueio em seguida. Se eu usar o dbappend() sem parametros após o bloqueio do arquivo ele ira desbloquear meu flock() ?

[Maligno]

Se eu usar o dbappend() sem parametros após o bloqueio do arquivo ele ira desbloquear meu flock() ?

Depende do valor que é default. No help não está especificado?

[Maligno]

se eu não sei mexer com code blocks

Se for para usar um código tecnicamente perfeito com algo desconhecido, talvez seja melhor aprender. O importante é saber reconhecer o valor do que é bom. E se é bom, vale a pena aprender.

Alguém já flagrou um cliente com um cronômetro na mão?

Há casos e há casos, Eolo. Numa repetição muito longa, o overhead do código extra se acumula. O que à primeira vista parece pequeno pode se tornar grande. Na maior parte dos casos, realmente, é improvável que se note algum atraso significativo. Nem se duvida isso. Mas numa malha de muitas iterações, é possível.

[Ademir]

O default é .t.

[Maligno]

Então, se o valor default é TRUE, todos os bloqueios serão desfeitos. Use o que for mais conveniente no seu caso.

[Euclides]

Olá pessoal! Desculpem a intromissão...
Eu utilizo o 5.3 há bastante tempo.
Nunca tinha reparado no parametro do dbappend()
em rede faço assim...

dbappend() // <- sem parametro deve fazer os ´unlocks´
replace campo1 with ...
replace campo2 with ...
dbrunlock()

isso sempre funcionou.
se o dbappend sem parametro faz os ´unlocks´, não deveria dar erro nos ´replaces´ ?
(só os meus 2 centavos)
T+
Euclides

[Ademir]

O guia de referencia do 5.3 diz o seguinte:

... is a logical data type that if true (.T.), clears all pending record locks, then appends the next record.

Pelo que entendí, o registro criado pelo dbappend() é o que fica bloqueado, tendo que ser liberado em seguida pelo dbrunlock(). Acho que é por isso que não dá erro.

Agora se são vários dbappend() o parametro (.T.) bloqueia apenas o atual, liberando o bloqueio dos anteriores.

Se estiver enganado, por favor algume me corrija.

[Euclides]

Pois é... EU é que deveria ir ao Reference Guide antes de começar a escrever.
O texto em inglés é claríssimo. Sempre se aprende algo novo.
Obrigado e até mais...
Euclides