PC Toledo

Compartilhando experiências.

Notei depois de alguns testes, que utilizando o antivirus ForeFront da Microsoft algumas rotinas do clipper dão pau e sujando os dbfs com aqueles símbolos. Principalmente quando utilizamos o comando PACK.
Este antivirus era usado em um servidor com Windows 2003. Desabilitamos o antivirus, e acabou-se os problemas.
Inicialmente tive dúvidas sobre a versao do clipper utilizado, 5.3b / CDX / Blinker 7 , mas fazendo alguns testes com o programa dbase, utilizando o comando PACK, com o antivirus habilitado dava probelma mesmo assim. Outra coisa o mesmo sistema roda em outras empresas que usa 2003 server, com outro antivirus (AVG) e roda sem problemas há anos.

Abraços a todos.



---
Nota da Moderação (Maligno):
O presente tópico foi movido da seção "CA-Clipper", uma vez que seu conteúdo diverge dos objetivos daquela seção, onde só podem constar matérias de cunho técnico, diretamente relacionadas à linguagem XBase com Clipper.

Olá!

O comando PACK realmente é um perigo... O melhor é criar a estrutura em outro DBF e copiar os registros não deletados. Depois deletar o DBF original e renomear o temporário.

Amiguinhos,

Eu já alertei aqui também os colegas em relação ao AVAST, ele também detona arquivos .DBF.

Outro agravante neste problema de corrupção, é o CACHE do Windows, pelo fato de demorar a gravar suas mudanças(gravação atrasada) este pode corromper os dados. gravando neles lixo, como por exemplo, páginas de internet abertas durante o uso do servidor com seu sistema.

Tá ai...

Senhores,

Uma pergunta: O comando commit não grava imediatamente o(s) registro(s) no o dbf? ou fica em cache?

[]´s

Olá!

Creio que isso funcionava no DOS. Sob o Windows, penso que o DbCommit() ou COMMIT envie uma requisição de gravação para o Windows. Este, de imediato, devolve uma resposta informando que os dados foram gravados mas, na realidade, esse pedido de gravação deve ficar numa fila de gravações do Windows (a tal gravação atrasada) que deve ser gerenciada segundo os critérios de prioridade de cada processo ou aplicativo. Tudo isso, eu acho... Bom tema para pesquisa.

No DOS, seja o real (kernel não-NT) ou o emulado (kernel NT), o comando COMMIT produz um flush (descarga) para disco de forma imediata, por meio de um interrupção (serviço) da API do DOS. Aliás, nem faria sentido tirar de um cachê para colocar em outro.
O que pode estar acontecendo é que o anti-vírus está "segurando" essa gravação em virtude da simples manipulação do arquivo. Antigamente o AVG também checava os DBFs, o que demandava mais tempo de análise heurística para verificar o arquivo, conforme um maior volume de dados. Apesar da extensão nada ter a ver com "executável". Lembro, inclusive, que alguns colegas resolveram esse problema, à época, incluindo seus arquivos de dados na lista de "exceções" do anti-vírus. Talvez esse seja o caminho para o presente caso.

Com relação ao comando PACK, aconselho o colega a utilizá-lo apenas em último caso. O ideal é elaborar rotinas de reaproveitamente de registros apagados, o que aliás torna o trabalho de inclusão mais rápido.

Certa vez tive um problema igual, num servidor que usava Avast. Apareceu um monte de logs dentro dos campos dos dbf´s.
Sobre o cache do Windows, o interessante seria desabilitá-lo. Tenho feito essa manobra em todos os pc´s que vão surgindo. Inclusive isso é recomendação das certificadoras de TEF, para o processo de homologação.

Olá!

Maligno escreveu:O ideal é elaborar rotinas de reaproveitamente de registros apagados, o que aliás torna o trabalho de inclusão mais rápido.

Sobre o assunto citado, existe um artigo muito bom e antigo, com exemplos, no também antigo site The Holmes Page. O título é Record Recycling.

Apesar de ser uma boa técnica, penso que seja trabalhoso fazer sua implementação em um sistema que já está pronto.

Pode ser realmente trabalhoso. Por isso, há anos insisto na questão da abstração. Se existe abstração, uma troca dessas se torna extremamente fácil.