Selecionar registros no dbedit

[robenfatti]

Caros amigos,...

Como fãço pra selecionar registros do dbf usando dbedit?

Grato.

[Eolo]

Eu uso um "macete" que talvez seja o que você procura. Seguinte: um cliente desejava selecionar registros ALEATÓRIOS num DBF (DBEdit ou Tbrowse), algo que não dava pra resolver com INDEX ou SCOPE ou outros. Era um trabalho digamos "manual".

A intenção? Por exemplo, mandar determinados registros pra impressão, ou deletar um conjunto de registros, ou alterar o preço de um conjunto de produtos etc.

O que eu fiz:
. criei um campo no DBF, chamado MARCADO, type Caracter, tamanho 1.
. criei um índice desse campo.
. na função de usuário do DBEdit ou Tbrowse, setei a tecla TAB (chr 9) para alternar o valor desse campo entre "1" (selecionado) e "0" (não selecionado).

O usuário então marca os registros desejados, um a um, e em seguida tecla digamos F5, para deletar o conjunto de registros marcados ou para alterar preços. O programa faz o seguinte (note que são só exemplos simplificados. Dá pra fazer qualquer coisa com os registros selecionados):

Código: Selecionar todos

* DELEÇÃO
use arquivo
inde on marcado tag marcado to arquivo
set inde to arquivo
do whil .t.
  seek "1"
  if !found()
    exit
  endi
  * bloqueia registro RLOCK()
  delete
endd
use

Código: Selecionar todos

* CORREÇÃO DE PREÇOS
use arquivo
inde on marcado tag marcado to arquivo
set inde to arquivo
do whil .t.
  seek "1"
  if !found()
    exit
  endi
  * bloqueia registro RLOCK()
  repl preco with round(preco*1,10,2)
  repl marcado with "0"
  * desbloqueia registro - UNLOCK
endd
use

Código: Selecionar todos

*Na função de usuário:

lk=lastkey()
*...
if lk=9
  * bloqueia o registro RLOCK()
  repl marcado with iif(marcado="1","0","1")
  * desbloqueia registro - UNLOCK
*...

[Eolo]

Em REDE, a coisa dá uma complicada, porque pode ter mais de um usuário querendo "marcar" o mesmo registro, e você não pode por exemplo deixar o usuário A desmarcar o registro marcado pelo usuario B, ou deixar o usuário C deletar um registro que o usuário A marcou para imprimir...

Eu resolvi essa "marcação em grupo" criando vários campos (marcado1, marcado2 etc), um para cada EXE rodando na rede. E, no caso da deleção, tomo alguns cuidados a mais. Mas é simples.

[robenfatti]

Ola amigos...

Não formulei bem a minha dúvida, mas de qquer forma vcs me responderam a dúvida q teria em seguida, vou exemplificar o problema:
O cliente tem uma locadora de equipamentos, tenho um DBF com todos equipamentos cadastrados, em determinada situação o cliente quer saber quais equipamentos estão locados (fora do estoque) e no dbedit quero mostrar somente os locados, tipo "data de retorno" em branco. Não estou conseguindo inserir esse "if" no dbedit.
Será q consegui explicar?

Roberto

[alaminojunior]

Bom dia.
Nesse caso precisa filtrar antes o que vc quer mostrar com o dbedit.
Se você usa RDDCDX, pode fazer uso do comando "Set Scope To" para mostrar apenas os registros que satisfazem a sua condiçao.
Se vc não usa RDDCDX, e sim o NTX, que é padrão, daí terá de usar, ou Set Filter (lento) ou, usar índices condicionais.
Mas é perfeitamente possível e fácil, usar quaisquer um deles. Nos diga qual RDD vc usa no momento, para podermos te ajudar melhor.

[Eolo]

É, eu me confundi com a sua pergunta.

[Pablo César]

Se a questão é exibir poucos registros na tela no estilo DBEDIT ou TBROWSE, eu indicaria fazer uma varredura dos registros com certa condição armazenando em MATRIZ e logo exibir através de TBROWSE de VETOR. Inclusive daria para criar uma coluna para pre-seleção.

[alaminojunior]

eu indicaria fazer uma varredura dos registros com certa condição armazenando em MATRIZ e logo exibir através de TBROWSE de VETOR.

Não tem necessidade nenhuma de mais trabalho, é só filtrar ( com Set Filter ou Scope ) que o serviço tá pronto.

[Eolo]

Se a questão é exibir poucos registros

Não dá pra vislumbrar, na pergunta inicial, se são poucos ou muitos registros. Pra mim, essa não foi a questão apresentada. A questão é "selecionar registros".

Na dúvida, vamos lá: em rede, se o colega armazenar registros em uma matriz e aí resolver fazer alguma coisa com esses registros (deletar ou alterar), como iria ser? Ele marca os registros na matriz mas, enquanto isso, outros usuários estão fazendo o mesmo em outras estações... Bloquear o arquivo, talvez? Mas aí nenhum outro usuário consegue trabalhar. Como o Alamino disse, é só um trabalho a mais.

Confesso que não entendi a sugestão.

[Pablo César]

eu indicaria

Isto significa que é mais uma sugestão. Dá trabalho, sim. Mas não tanto. Não entende por quê ? Eu digo, fazer alterações ordenações, seleção de registros ou em elementos de matriz tem melhor desempenho do que direto no arquivo de dados diretamente, essa é a minha opinião, ja que trata tudo na memória. E ainda, tem a vantagem de que na edição dos registros, não precisar tratar na hora. Só precisa na hora de atualizar quando repassa para o arquivo de dados.

Uma vez que o programador tenha desenvolvido seu TBROWSE a contento, fica fácil para o futuro vir a reutilizar adpatando pouca coisa do código. Mas calma aí gente, essa é a minha opinião. Eu nunca disse que os colegas sugiriram estivessem ERRADOs. Eu por exemplo "detesto" utilizar SET FILTER e como o colega Eolo mencionou o Tbrowse é viavel, principalmente se tiver que marcar registros para realizar alguma operação de atualização no arquivo DBF, por exemplo deletar em bloco, replace em bloco, copiar... etc.

[acelconsultoria]

Essa é uma questão interessante... e se tem uma coisa que ainda não me deixa satisfeito no meu sistema é realmente essas rotinas pra marcação de registros para operação em bloco. Apesar de ter desenvolvido e estar funcionando sem problemas, penso que ainda pode ser melhorada ou reescrita.

Os problemas mais comuns:

- Mais de um usuário podem estar marcando registros diferentes na mesma tabela, em terminais diferentes, aí vai saber quem marcou o quê ?!!!
- Se cair a energia, e os registros permanecerem marcados. Aí, sem saber outro usuário entra na rotina, e sem saber que tal registro está marcado, manda executar determinada função. Aí, altera algum registro que não deveria ser alterado.

A maneira como tento "cercar" isso: Eu faço algo parecido com o Eolo: Tenho um campo dentro do DBF com o nome "CHAVE, C, 1" e outro "USUARIO, N, 3" com o código do usuário que está acessando, possibilitando que as seleções sejam específicas para cada usuário. Aí, dá pra separar o que o usuário 001 e 002 marcaram respectivamente, por exemplo. Já no caso do desligamento indevido, resolvo mandando um comando pra limpar todas as "marcações" antes de abrir o registro na tela pro usuário marcar.

E não é nada rápido operar assim !!! Alguém usa esse mesmo tipo de operação, mas de maneira melhor

[Eolo]

Já no caso do desligamento indevido, resolvo mandando um comando pra limpar todas as "marcações" antes de abrir o registro na tela pro usuário marcar. E não é nada rápido operar assim !!! Alguém usa esse mesmo tipo de operação, mas de maneira melhor

Sato,

Primeiro, hoje um no-break não é tão caro e é quase obrigatório ter. Independente disso, é preciso ter rotinas de verificação das gravações: se um processo é interrompido prematuramente, quando voltar a energia o seu sistema tem que saber que algo ficou pendente e que é preciso completar o processo interrompido.

Segundo, esse mecanismo que eu uso, do campo MARCADO, não é pro usuário marcar por exemplo 12.000 registros (estou exagerando, só pra exemplificar). Se é pra alterar um campo no DBF inteiro, é outra história... Então, o mecanismo é pra "poucos" registros. No meu caso, como eu tenho esse campo INDEXADO e desmarco usando com o SEEK, o processo de desmarcar digamos 100 ou 200 registros é quase instantâneo.

Por que o seu processo demora tanto?

Código: Selecionar todos

use arquivo
set inde to arquivo
set orde to 1
do whil .t.
  seek "1"
  if !found()
     exit
  endi
endd
use

COMPLEMENTANDO: Acabei de fazer um teste aqui. Não é Clipper (é XHarbour, acessando a base de dados lá no cliente, via Terminal Service), mas dá pra ter uma idéia. Marquei 594 produtos e saí sem pedir nenhuma providência (o programa só desmarca o que eu marquei). Segundo o cronômetro: quase 2 segundos! É quase nada.

[Eolo]

seleção de registros ou em elementos de matriz tem melhor desempenho do que direto no arquivo de dados diretamente, essa é a minha opinião, ja que trata tudo na memória. E ainda, tem a vantagem de que na edição dos registros, não precisar tratar na hora.

Pablo, eu concordo que o processamento na memória é mais rápido.

Mas não concordo com a segunda parte da sua observação. Em uma rede, com mais de um usário lidando com a mesma base de dados, como é que não precisa tratar na hora?! Lógico que tem! Imagina uma loja de aluguel de carros: o usuário UM está trabalhando com 10 veículos disponíveis [em um array], enquanto que todos os 10 veículos já foram alugados pelo usuário DOIS, que finalizou o processo antes que o usuário UM...

Estoque é um outro bom exemplo.

[robenfatti]

Obrigado a todos pelas dicas, vou fazer alguns testes com MATRIZ e um outro usando um DBF temporário.

Valeu.

Roberto