PC Toledo

Caros amigos,...

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

Grato.

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):

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.

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

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.

É, eu me confundi com a sua pergunta.

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.

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.

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 escreveu: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.

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

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?
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.

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.

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

Valeu.

Roberto