o Tal Corruption Detect

[juniorcamilo]

Amigos será que nao tem como elaborar um funcao que trate este erro, e que mesmo com o erro ele grave o registro nos arquivos e c o relatorio que seje sair errado paciencia, mas que garanta a gravação e depois com a reorganizacao dos indices arrume isto..c eu nao me engano sempre este erro acontece quando c usa APPEND,COMMIT,UNLOCK ou o travamento do registro,,, iai tem jeito????

[rochinha]

Amiguinho

Este erro pode ocorrer por vários motivos e muitas vezes intermitentes.

Um deles é a falta de espaço em seu HD.
Outro é a memória disponivel para rodar seu aplicativo.
Outro é voce estar deixando de abrir todos os indices em algum lugar de seu sistema.

Exemplo:

Voce tem o arquivo.DBF com os indices ind01, ind02 e ind03.

Voce sempre usa o comando:

Código: Selecionar todos

...
use arquivo index ind01, ind02, ind03
...

Mas em dado momento voce faz isto:

Código: Selecionar todos

...
use arquivo index ind01, ind03
...

ou isto:

Código: Selecionar todos

...
use arquivo index ind01, ind03, ind02
...

Por um bom tempo isto pode funcionar, mas quando voce der o comando:

Código: Selecionar todos

...
use arquivo index ind01, ind02, ind03
...

Este erro poderá ocorrer.

Por enquanto não me lembro de outras situações, mas por hora, verifique.

[Stanis Luksys]

Tem também aquela rotina destruidora de DBFs que altera o cabeçalho do arquivo fisicamente, e possibilita a recuperação.

Talvez alguém a tenha usado neste DBF.

[juniorcamilo]

olha quanto as possiveis situações citadas, nao tem este problema no sistema oq mais ocorre é queda de energia, usuario metendo o dedao no micro, fachineira passando o rodo na tomada e etc,,,, mas erro de logica em abertura de arq. e indice nao....

[Maligno]

Pra detectar erros (e fraudes) nos DBFs eu reservo o último campo do registro para armazenar o CRC32 do conteúdo. Na aplicação, ao precisar de um registro, recalculo o CRC32. Se for diferente do que está gravado, de duas uma: corrupção de dados ou algum curioso meteu o nariz onde não foi chamado.

Esta técnica não resolve a corrupção quando os fatores envolvidos estão fora do nosso alcance. Mas tão ruim quanto a existência da corrupção é quando não sabemos que ela existe. E pior: quando ela é sutil o suficiente para o programa não abortar, mas daninha o suficiente para produzir resultados errados.

[Pablo César]

Pra detectar erros (e fraudes) nos DBFs eu reservo o último campo do registro para armazenar o CRC32 do conteúdo.

Legal esse procedimento, muito útil quando queremos preservar a veracidade dos dados, principalmente quando existe algum sabichão que pode mudar o DBF por fora do sistema. Mas tenho uma pergunta sobre esse esquema, Maligno: digamos que o sabichão apague esse campo que contém o CRC32, isto é, o deixa em branco e depois entrar em modo "alterar" do seu sistema. Imagino que é verificado isso também no seu procedimento, não é ?. E quando você precisa fazer alguma alteração para o cliente, imagino que deve ter algum macete ou aplicativo extra para validar o CRC32.

[Pablo César]

Quando não há necessidade de "policiar" o conteúdo dos campos, eu trato qualquer erro ocorrido no ERRORSYS para que entre na rotina de INDEXAÇÃO. Claro que gerencio tudo isso mediante meu principal arquivo BAT. E ainda coloco a rotina de indexação no protetor de tela, claro também que antes é verificado:

- Se o protetor de tela acionado é do SERVIDOR ou ESTAÇÃO
- Se não existe arquivo DBF aberto em alguma estação

Também faço uma rotina de escape no GETs críticos. Aqueles que o usuário fica neles por horas enquanto vai almoçar em casa e deixa aberto no módulo de inclusão/alteração sem digitar nada.

[Maligno]

Maligno: digamos que o sabichão apague esse campo que contém o CRC32, isto é, o deixa em branco e depois entrar em modo "alterar" do seu sistema. Imagino que é verificado isso também no seu procedimento, não é ?. E quando você precisa fazer alguma alteração para o cliente, imagino que deve ter algum macete ou aplicativo extra para validar o CRC32.

Fiz esse esquema também pelo fato do DBF ser facilmente modificado por usuários mais esclarecidos no assunto.
Se alguém quiser modificar o campo do CRC32, inserindo qualquer valor ou mesmo tornando-o branco, o programa, ao recalcular o CRC, sentirá a disparidade dos CRCs e já vai reclamar. Não tem como escapar disso. Mesmo que o valor original do CRC gravado seja modificado.
Quando preciso modificar a estrutura de algum DBF, claro, atualizado os valores dos CRCs de todos os registros para refletirem também a alteração feita.

Em tempo: o algoritmo que eu uso é modificado. Mesmo que o usuário também seja esclarecido nessa área, não tem como ele simplesmente gerar um CRC com as alterações que ele queira. Isso é meio drástico. Dificilmente alguém se daria a tanto trabalho apenas para forjar algum registro. Mas, é como eu digo: se é pra fazer, que seja bem feito.

[Pablo César]

Dificilmente alguém se daria a tanto trabalho apenas para forjar algum registro. Mas, é como eu digo: se é pra fazer, que seja bem feito.

É também tem aquela questão do escriptar o DBF, isso também iria dificultar mais ainda.. Enfim, acho que em informática não existe nada totalmente seguro, mas que dá para dificultar... dá.

[Maligno]

É também tem aquela questão do escriptar o DBF, isso também iria dificultar mais ainda..

Nunca me passou pela cabeça de usar criptografia para dados de um DBF inteiro. Há campos sim, que você poderia querer esconder. Aí acho válido, desde que o registro em si se mantenha criptografado, trabalhando com o dado original apenas em memória. Mas são poucos os casos. Senha não é um deles. Ela depende apenas de um hash qualquer. Só um programa meu, que faz log-in em servidor POP armazena senha. O resto é senha de programa. Aí só armazeno o hash mesmo.

Enfim, acho que em informática não existe nada totalmente seguro, mas que dá para dificultar... dá.

Qualquer sistema de proteção, seja do que for, estará tão mais seguro quanto menor for a ganância e experiência técnica do público alvo. Como a maioria de nós trabalha com simples sistemas de informação, não há por quê se prender tanto a essas questões.

[juniorcamilo]

Ainda sim o unico erro que tenho com os cliente e o velha queda de energia, e usuario metendo o dedao no botao do micro,,, ou ate mesmo XP abortando o sistema, ai é dito e feito Corruption Detect, sabichoes aqui no Sul do Pará nao tenho p´roblema em usuarios curiosos com os DBfs.... tentei colocar o errosys.. onde abre o arquivo tipo
Local erro := ErrorBlock( {|e| VerErro(e)} )
mas ai ele trata todo o exe e nao so a funcao especifica!!!