CAMPO USUARIO nos DBF's E DBCOMMIT()

[Eliane]

Estou trabalhando em um sistema clipper52.e e BLINKER.

Para controlar o acesso na rede todos os dbfs tem um campo de USUARIO. Quando o USUARIO acessa o reg. seu código fica gravado no DBF. Assim, os demais que acessarem somente poderao fazer consultas e saberão o nome do USUARIO que está controlando o registro. Quando o USUARIO controlador libera o registro, o campo usuario é gravado com espaços. Funciona bem.

Minha dúvida é:

- Tenho que dar um replace em cada dbf para gravar o nome do USU
- Tenho que comparar os usuarios antes de liberar um registro
- Tenho que dar um replace cada vez que o USUARIO controlador liberar o registro ( mesmo que não tenha modificado nada).

- Uso o dbcommit() na gravação de cada registro porque tenho receio, de na rede, ter problemas de integridade dos dados se não usar.

Alguém tem noção até que ponto estas gravações constantes podem comprometer a velocidade do sistema e a integridade dos dados. Meu servidor é LINUX.

[MARCELOG]

Eliane,
verifique o tópico no www.caclipperwebsite.com .
Eu aprendi a técnica em face da matéria publicada no mesmo.

Para integridade de dados em rede, criei um registro que guarda a hora da gravação.

Em linhas simples, faço o seguinte:
- Inlcusão.
Vou para o registro "fantasma" e igualo as variáveis.
Se confirmada a inclusão, uso dbappend() - que já trava o registro - e efetuo a gravação registro, sendo que no campo próprio, a hora da mesma.

- Alteração/ Exclusão.
Guardo a hora constante do registro numa variável.
Igualo variáveis.
Se confirmada a alteração, verifico se a hora registrada no arquivo ainda é a mesma que está na variável guardada.
Se for, travo o registro e efetuo a gravação/ deleção.
Se não, informo ao usuário que ele foi "lerdo" e, que, enquanto digitava ou resolvia o que fazer da vida, alguém alterou o registro.

É mais ou menos isso.

No site do Anderson, indicado acima, tem a técnica de saber o nome do "sem serviço" que travou o registro e foi namorar (eu espero).

Também é legal e não dá tanto trabalho.

Assim, você evita ficar travando desnecessariamente registros.

MarceloG

[rrfsistemas]

Olá Eliane !

Alguém tem noção até que ponto estas gravações constantes podem comprometer a velocidade do sistema e a integridade dos dados. Meu servidor é LINUX.

Em relação a sua pergunta : o acesso a disco é muito mais lento do que o acesso ao buffer de leitura e gravação.

Se vc usa o commit vc esta forçando o acesso a disco em todas as suas operações de cadastro e alteração.

Vc já ouviou falar em buffer OTIMISTA E BUFFER PESSIMISTA ?

Vamos lá :
BUFFER OTIMISTA :uma maneira eficiente de atualizar registros, pois os bloqueios são aplicados apenas no momento em que o registro é gravado, minimizando, assim, o tempo durante o qual um único usuário monopoliza o sistema em um ambiente multiusuário.

BUFFER PESSIMISTA : impede que um usuário em um ambiente multiusuário acesse uma tabela ou um registro específico enquanto outro usuário estiver fazendo alterações nele ou nela. Oferece o ambiente mais seguro para alterar registros individuais, mas poderá tornar as operações do usuário mais lentas.
Vc pode escolher um dos dois casos, no 1º basta gravar o nome do usuário e a hora(baseada no servidor) em que foi feita a alteração.
Espero ter ajudado... :xau