verificar se registro está bloqueado.

[matrix]

Bom dia pessoal,

como identifico se o registro está bloqueado (Rlock)

quero fazer o seguinte:
cadastrar cliente novo, se um terminal abrir o cadastro de clientes ele pegará o contador ultimo +1, se ja estiver sendo usado esse registro na rede, entaum pegará ultimo + 2.

agradeço.

[vailton]

Desculpe, mas acho q esta lógica ñ está correta. Imagine 10 terminais numa rede e os 10 clicando em INCLUIR ao mesmo tempo.... qtos registros duplicados irão ocorrer?

Acho q o mais correto seria:

* Crie 1 variavel numerica
* Travar o registro. Se travado some +1, guarde o valor na variavel criada acima e desbloquei o registro.
* Não travou? tente de novo...

Se travado e td OK, retorne o valor atual da variavel numerica, acho mais seguro algo assim.

[matrix]

concordo parcialmente, entaum esbarro em outro problema.

a rotina é assim: se digito o codigo do cliente ele me retorna os dados, caso contrario incrementa e cadastra um novo.
mas terei entaum que após o inicio do cadastro gravar ao menos o campo CODIGO, pra que se outro terminal acessar, incrementar no que estou no momento, e assim sucessivamente.
mas e se eu aborto antes de gravar todos os dados e outro terminal ja pegou o codigo seguinte, vai furar a sequencia.....td bem q naum seria grande problema mas........

agradeço se essa for a logica.

[Eolo]

Eu sou mais conservador ainda. Num caso desses, pra não haver nenhuma chance de duplicidade em campos-chave, eu bloqueio o arquivo com FLOCK() e primeiro confirmo se o nome já não existe. Se não existir, APPENDo um novo registro, faço os REPLACE e depois libero.

O processo é rápido e, mesmo com o FLOCK(), o arquivo continua livre pra leitura, na rede. Além disso, incluo ainda um número de tentativas de bloqueio...

Eolo

Código: Selecionar todos

Exemplo...

function novocliente(vnome)
priv vnovo,tentativas:=5
sele clientes // já aberto SHARED, com índices NOME e CODIGO
do whil .t.
  if flock() // =.t.
    exit
  endi
  inkey(1) // pausa
  tentativas--
  if tentativas=0
    ?"Incapaz de bloquear arquivo"
    retu .f.
  endi
endd
set orde to nome
seek vnome
if found()
  ?"Nome "+alltrim(vnome)"+" já cadastrado"
  unlock
  retu .f.
endi
set orde to codigo
go bott
vnovo=codigo+1
appe blan
repl codigo with vnovo
repl nome with vnome
*etc.
unlock
retu .t.

[MARCELOG]

Oi Pessoal,
neste fórum existem várias dicas para numeração sequencial.
Tem uma que gera um arquivo texto que contém esse número, e é incrementado em cada inclusão (vi primeiro em www.caclipperwebsite.com).
Outra que usa arquivo dbf e admite recuperar números excluídos (digite numeração em "Busca").
E mais essa do Eolo.
Todas estão valendo, depende do seu jeitão de programar.

MarceloG

[Maligno]

Eu não uso nenhum sistema de armazenamento interno ou externo. Pegar o último número e incrementar me parece ser a pior forma. Eu uso simples números aleatórios. Gero o número e procuro na base (dificilmente encontra). É rápido, já que há, logicamente, uma chave para esse código. Se encontrar, gero outro número. Não encontrando, fim. Fácil, rápido e seguro. Sem bloquear nada.

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

[Eolo]

MarceloG,

Se eu entendi, essa opção de "recuperar números excluídos no DBF" seria o reaproveitamento de codigos, certo? Se for isso, eu acho temeroso (considerando uma forma "padrão" de estrutura da base de dados).

Explico: se vc tem o MarceloG cadastrado como 12345 e, no resto do sistema (vendas.dbf, compras.dbf, a_pagar.dbf etc.), uma série de registros fazendo referência ao código 12345, que é do MarceloG, e aí vc deletar o MarceloG no nomes.dbf e atribuir o mesmo código 12345 pro Eolo, os registros dos outros arquivos vão ficar "errados", vc vai ferrar o seu histórico. Pra evitar isso, vc teria que reconstruir todo o seu passado, talvez deletando (será que vai poder?) todas as referências anteriores ao 12345.

Por outro lado, se vc fizer por ex o campo CODIGO com tamanho 9, vc pode ter até 100 milhões de códigos diferentes, aí não vai precisar "reaproveitar" códigos. E por um bom tempo...

Eolo

[MARCELOG]

Tudo bem Maligno,
eu ressaltei o "jeitão de programar" de cada um.
E ressalto a lei de Murphi, segundo a qual tudo que pode dar errado vai dar, e o cliente/ usuário.
Isso mesmo, o cliente/ usuário, aquele que jura de pé junto que estava a há mais de 10 metros da máquina quando o hd foi reformatado.
É que alguns clientes/ usuários (santo perfeccionismo) gostam de algumas coisas (e ele tem razão segunda a lei da "oferta e procura").
Por exemplo, tenho um cliente que quer numeração fixa e crescente, com utilização de número excluído para determinados registros.
Ele me diz que "não consegue admitir", por exemplo, excluir o cliente 90 e o próximo cliente ter o número 201.
Com aquele ar de organizado exclama: __ É muio desperdício não aproveita o código 90 que eu exluí! (vai enteder...)
Outro já quer flexibilidade, e quer criar o código, que pode ser númerico, caractere ou alfanumérico.
Internamente, tudo bem, e você com o seu conhecimento e lógica, administra perfeitamente uma base com códigos e referências.
Eu mesmo uso um código interno, que amarra as referências, mas dou ao cliente/ usuário a possibilidade de criar um código, que chamo de ordem, para os diversos registros.
Essa ordem é criada como a sua, ou seja, aleatoriamente.
Assim, ao incluir, apresento a ordem aleatoriamente criada para ser aceita ou alterada pelo cliente/ usuário, fazendo a verificação de duplicidade e alteração quando a operação é concluída.
Nunca tive problemas.

MarceloG

Ps: a gente sabe que o computador é lógico. A possibilidade de criar algo aleatório idêntico com base em radomização é "quase" impossível.
Mas como é "quase", melhor se garantir.

Sem críticas, apenas algo para os colegas refletirem.
Eu gosto do CRUZEIRO ESPORTE CLUBE, e há controversas.

[Eolo]

Maligno.

Se encontrar, gero outro número. Não encontrando, fim. Fácil, rápido e seguro. Sem bloquear nada.

Mas e em rede? Se duas estações gerarem o mesmo código aleatório e o APPENDarem, como fica?

Eolo

[MARCELOG]

Eolo,
sempre gostei de clipper (agora tô apaixonado pelo xhatrbour), e tive a sorte de conseguir com um amigo programador dois livros velhos sobre o assunto.
Um do Ramalho: Clipper II e o outro do Rick Spence.
O primeiro é bem didático e o segundo a bíblia.
Para evitar o que você disse o Rick aconselha, e eu uso, a deleção em cascata. Se o principal é excluído, os dependentes têm que ser.
Não tem erro.
E conforme eu disse, sou clipper do tempo em que ms-dos era padrão.
Economizo tudo: memória, campo, programação, etc.
Até hoje não sei ficar com muitas janelas abertas no computador.
O mundo tá globalizado e, talvez, se você vender seu sistema para a China ou Índia, 100 milhões de registros para um cadastro de clientes é nada.
O Brasil tem 200 milhoes de habitantes né?
Um abraço.

MarceloG

[Maligno]

eu ressaltei o "jeitão de programar" de cada um.

Ah, sim. Claro. Eu apenas ressaltei o meu.

Por exemplo, tenho um cliente que quer numeração fixa e crescente, com utilização de número excluído para determinados registros.

A maioria dos clientes que pedem esse tipo de coisa sequer sabem porque querem isso. Muitos pedem isso porque foram condicionados a fazer assim. Certo dia um amigo me contou que foi atender o chamado de uma possível nova cliente. A mulher mostrou um caderninho onde ela fazia todos os seus controles manuais e disse: eu quero um programa que seja idêntico a esse caderninho. Pobre coitado! ))

Mas essa questão de numeração eu resolvi de forma bem mais simples. Além de gerar os códigos (de qualquer coisa) aleatórios, eu tirei os códigos da vista dos usuários. Ninguém usa códigos desse tipo pra nada. Logicamente o meu sistema de busca foi aprimorado pra não dar mais trabalho pro usuário. Felizmente nenhum cliente me pediu esses códigos. E nem se pedisse eu faria.
Mas é claro que eu me refiro apenas aos códigos das chaves primárias de referência. O cliente não tem acesso a eles. O cliente apenas monta, ele mesmo, os códigos de identificação que devem ser montados por ele. Um exemplo: código de identificação de matérias-primas, que usa o estilo plano de contas.

Enfim, cada qual com a forma que acha melhor. Só descrevi a minha técnica para talvez inspirar alguém a aprimorar a sua.

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

[Maligno]

Mas e em rede? Se duas estações gerarem o mesmo código aleatório e o APPENDarem, como fica?

Já respondi. Antes de considerar o código válido, busco o mesmo no arquivo, pelo índice. Se ele já existir (quase impossível de ocorrer), gero outro e repito o teste, até conseguir um número válido. O número é compactado, mas é largo o suficente para dificultar ao máximo qualquer colisão.

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

[Maligno]

Por outro lado, se vc fizer por ex o campo CODIGO com tamanho 9, vc pode ter até 100 milhões de códigos diferentes, aí não vai precisar "reaproveitar" códigos. E por um bom tempo...

Você está vendo o número como um número comum que, com 9 dígitos, acomodará 1 bilhão(-1). Se você compactá-los, esses mesmos 9 dígitos poderão acomodar mais de 500 quatrilhões. Aliás, essa é uma das minhas principais justificativas pra usar números aleatórios nos códigos.

Agora, com relação ao reaproveitamento que o Marcelo comentou, também é muito válido. O apagamento em cascata que ele faz resolve o problema perfeitamente. Há casos, claro, que o apagamento da chave primária implica no prévio apagamentos dos registros referenciados. E há outros casos em que o apagamento deve ser proibido. Depende. A única coisa que não pode é apagar a chave primária e deixar registros órfãos. Mas isso é o básico que todo mundo sabe.

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

[Eolo]

Maligno,

Você está vendo o número como um número comum que, com 9 dígitos, acomodará 1 bilhão(-1).

Eu simplifiquei, sem falar em compactação, conversão ou outras, pq esse não era o ponto. Eu só quis ressaltar que seria meio difícil precisar reaproveitar códigos tendo 1 bilhão de números diferentes...

...Se ele já existir (quase impossível de ocorrer), gero outro...

Eu não acho que "quase" seja adequado numa situação dessas. Ou o novo código é 100% único ou não é. Se não, fica igual à tal história, "mãe, to quase grávida..." eh eh eh

...Além de gerar os códigos (de qualquer coisa) aleatórios, eu tirei os códigos da vista dos usuários...

Abrindo um pouco o foco deste ponto, eu já vi colegas se referindo à idéia de abolir códigos em seus programas, mas nunca entendi isso direito. Se em praticamente tudo é usado código, em que casos se poderia prescindir deles? Ou em quê isso [a ausência do código] seria melhor em termos de processamento ou armanezamento, ou ainda de facilidade operacional pro usuário?

Um desses colegas argumentou comigo que achava terrível, por exemplo, uma pessoa ir ao banco e ser reconhecido não pelo nome, mas por um número. Po, se EU for no banco e pedir um extrato pelo meu nome, qq atendente vai ficar meia hora tentanto "Eulo", "Euro", "Lolo" etc. (é sério, isso acontece!). Mais fácil é digitar "6450", o número da minha conta...

...controles manuais e disse: eu quero um programa que seja idêntico a esse caderninho...

Cara, eu acabei de pegar dois clientes, batendo software houses famosas. O primeiro, um hotel: o dono testou um dos mais conhecidos programas de hotelaria que existe e não conseguiu usar (muito complicado, segundo ele). Aí montei o que ele precisava, semelhante à "cadirneta" dele, e ele mandou deletar o outro. Outro cliente é um supermercado, que tem um programa famoso rodando, mas que vai ser substituído por um meu em uns 60 dias... Mesma coisa.

Este é um ponto que eu discuto muito. Óbvio que é tudo muito relativo, depende do tamanho do cliente, da sua estrutura, do seu ramo de atividade, da cultura pessoal dos donos etc., e ainda por cima vc tem que assegurar um mínimo de consistência e integridade dos dados do sistema, mas eu acho o seguinte: via de regra se esquece do usuário, da capacidade dele usar um sistema, e se faz coisa que acaba atrapalhando ao invés de ajudar. É aquele exemplo sobre o qual já falamos: me aponte, por exemplo, um usuário comum que utilize mais que 10% da capacidade do MSWord...

Então, não se trata de ser "retrógrado", mas se o usuário fatura 50mil por dia controlando cheques numa "cadirneta", por quê forçar ele a outra coisa?

Eolo

[Maligno]

Eu não acho que "quase" seja adequado numa situação dessas. Ou o novo código é 100% único ou não é. Se não, fica igual à tal história, "mãe, to quase grávida..." eh eh eh

Você não me entendeu. O "quase impossível" é um pensamento que faz parte da minha obrigação de me prevenir. Veja: eu disse que após gerar o número TESTO SUA EXISTÊNCIA. Se o "quase impossível" acontecer e ele já tiver sido utilizado, GERO OUTRO NÚMERO e testo novamente. Esse esquema nunca me falhou. Dificilmente vou precisar gerar um segundo número.

Abrindo um pouco o foco deste ponto, eu já vi colegas se referindo à idéia de abolir códigos em seus programas, mas nunca entendi isso direito. Se em praticamente tudo é usado código, em que casos se poderia prescindir deles?

Quando você está interagindo com uma empresa e quer ser rapidamente identificado, é válido fornecer a eles uma identificação numérica que seja única. Um número de conta corrente num banco é uma identificação simples. Não é do feitio deles, mas eles poderiam utilizar seu CPF ou mesmo seu telefone, que são identificações únicas.
Meus clientes não usam código algum. Há várias formas de buscar o cliente sem usar um código numérico. Ele pode usar uma tabela com pesquisa incremental pelo nome (ou CNF/CNPJ) ou mesmo o GET do nome digitando parte do nome ou parte do CPF/CNPJ ou o número do telefone. Na eventualidade de nomes/números parciais coincidirem, automaticamente o sistema faz aparecer um browser que contém apenas estes poucos registros.
Nunca gostei de usar códigos de identificação. Usei uma vez na vida. Não gostei do resultado e apaguei tudo. O cliente, à época, gostou muito da troca.
Não há uma perda na facilidade operacional, mas sem dúvida é um número a menos pra atrapalhar. E em termos de processamento ou armazenamento, claro, não faz diferença.

Um desses colegas argumentou comigo que achava terrível, por exemplo, uma pessoa ir ao banco e ser reconhecido não pelo nome, mas por um número.

O banco nem precisaria do número da conta do cidadão, a princípio. Eles usam por dois motivos: o cliente obrigatoriamente precisa ter um número de conta corrente. E segundo, se tem, ele precisa saber qual é. Logo, fica mais fácil usar o número da conta. Não há necessidade disso, mas o banco poderia muito bem usar o CPF ou telefone.

montei o que ele precisava, semelhante à "cadirneta" dele, e ele mandou deletar o outro. Outro cliente é um supermercado, que tem um programa famoso rodando, mas que vai ser substituído por um meu em uns 60 dias... Mesma coisa.

Já tive clientes absurdamente burros que não se davam bem nem com máquina de calcular com quatro operações. Pra esse tipo, qualquer coisa é complicada demais. Mas não aceito a idéia do "caderninho" e não aceito que o software seja excessivamente complicado. Um meio termo é sempre mais apropriado. A gente tem que trabalhar muito pra que o cliente trabalhe menos e de maneira bem fácil. Mas sem deixar de lado o rigor inerente ao sistema. Em certos tipos de negócios, a solução exige alguma complexidade. Cada caso é um caso.

depende do tamanho do cliente, da sua estrutura, do seu ramo de atividade, da cultura pessoal dos donos etc.,

Exatamente. Esse é o ponto.

via de regra se esquece do usuário, da capacidade dele usar um sistema, e se faz coisa que acaba atrapalhando ao invés de ajudar.

Isso tudo eu ignoro. Prefiro perder o cliente. Não vou deixar de fazer bem feito o meu trabalho só porque o cliente não tem conhecimento ou disposição suficente para aprender o básico, só porque ele acha "complicado". Ele também tem que se dispor a aprender algo novo às vezes.

Então, não se trata de ser "retrógrado", mas se o usuário fatura 50mil por dia controlando cheques numa "cadirneta", por quê forçar ele a outra coisa?

Porque ele poderia faturar mais ainda se tivesse uma ferramenta de tabalho melhor. Na medida que você o ajuda a expandir seus conhecimentos, deixando pra trás os conceitos antigos/arcaicos, você o está ajudando a melhor compreender que a informática pode oferecer muito mais do que um simples "caderninho". A partir daí é conseqüência: a situação dele só tende a melhorar. E você ainda corre o risco de ganhar um fã.


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