Registro nao e atualizado quando tem dois programas abertos

[rubens]

Olá pessoal...
Desaprendi ou tô fazendo algo de errado. Seguinte, no meu programa o usuario coloca o limite do cliente no cadastro do cliente, daí na hora de fazer a venda se o cliente tá bloqueado ou com limite ultrapassado aparece uma mensagem e volta para tela de lancamentos de itens. Daí um usuário com senha de supervisor entra no cadastro e desbloqueia ou aumenta o limite. Daí o vendedor que esta com a tela de vendas aberta tenta fechar o pedido de novo. Só que aí num atualiza no registro daquele cliente a informação alterada pelo usuario de nivel superior. O cliente tem que cancelar essa venda e pesquisar o cliente de novo para atualizar. Porque ele não está atualizando???
O arquivo é aberto no modo compartilhado, na rotina de alteração de cadastro do cliente na finalização tem um commit, antes do commit testo se o registro foi travado ou não com o rlock, não aparece nenhuma msg de erro, mas na tela de vendas onde o arquivo está compartilhado nao atualiza... somente quando o vendedor cancela a venda e busca o codigo do cliente de novo..

Se alguem puder ajudar ai fico muito agradecido...

Vlw...

Rubens

[alaminojunior]

Desaprendi ou tô fazendo algo de errado.

A experiência nos leva a crer que a segunda opção é mais aceitável.
Verifique se você não está guardando este limite em alguma variável que não está sendo atualizada com base no novo valor do registro.

[rubens]

Pois é Júnior... tb pensei assim no início... já vi e revi a rotina vária vezes... só que tem um detalhe se tivesse algum erro com as variáveis não atualizaria quando busca o cliente de novo. Tá com algum erro no tempo de gravação desse commit ou o windows num tá salvando o buffer ou sei lá "tem alguns anõezinhos dentro do pc"... brincadeira... já testei na rede... só na máquina... já saí do programa que atualiza para ver se enquanto tava aberto o commit num tava funcionando, já troquei commit, por dbcommit(), por dbcommitall()... e nada... num precisa nem fechar o programa, basta sair da tela de vendas, fechar e abrir o clientes.dbf de novo que ele busca a o registro alterado... e tô usando pra verificação o compo direto do dbf com o aliás e o nome do campo no caso cli->limite ...

Rubens

[JoséQuintas]

Faça um teste simples:
select clientes
skip 0 ' zero, isso mesmo
if valorpedido > credito->clientes

Se isso não resolver, então melhor acompanhar pelo debug e verificar na linha da análise.

[rubens]

Opa... Obg José Quintas e AlaminoJúnior... a solução do José Quintas resolveu o problema, coisinha simples e meio gambi... mas resolveu o problema...
Obrigado

Rubens

[alxsts]

Olá!

Acho que não é "gambi" não... O DbSkip(0) força uma releitura do registro atual em uma área.

[JoséQuintas]

O conteúdo do registro atual está na memória, e não no disco.
Ao fazer um Skip, o Clipper entende que mudou a posição, e atualiza os dados.
Também vale pra gravação. Raramente uso commit, costumo usar Skip 0, antes do unlock.
Se não fosse assim, a cada "say cliente->campo" teria que haver uma nova leitura física, o que tornaria tudo lento.

[alaminojunior]

O fato é que DbSkip(0) resolveu neste caso. Mas o uso do Commit devería surtir efeito. Deve ter algo fora de posição aí.

[alxsts]

Olá!

Se não me falha a memória, tem alguma chave do registro do Windows que interfere no DbCommit().

[JoséQuintas]

Nada a ver, porque a diferença é quanto a leitura, e não quanto à gravação.
Faça o teste prático, e tente alterar o de gravação pra ver se faz diferença.
Depois coloque um skip 0 no primeiro
Detalhe: nem precisa rede, pode ser duas janelas do windows.

Código: Selecionar todos

// terminal de consulta
procedure Main
set exclusive off
use jpcadas
mInkey := 0
do while minkey != 27
   @ 12, 20 say cdnome
   Inkey(0)
enddo

// terminal da alteração
procedure main
set exclusive off
use jpcadas
rlock()
replace cdnome with "XCOM"
quit

[alaminojunior]

Se não me falha a memória, tem alguma chave do registro do Windows que interfere no DbCommit().

Uma coisa que sempre desabilito por segurança do programa e do próprio usuário, é o cache de disco do Windows, seja qual for a versão.

[JoséQuintas]

Bom... Desde a época do W98, a única coisa que mexo é o FILES=200.
Nem SET CLIPPER=, porque isto fica embutido no EXE.
Problemas? Acho que foi no ano passado que precisei reindexar num dos clientes, após quedas de energia.