Arquivo .DBF corrompido (Read Error)

[trooper7]

Olá, pessoal, bom dia!

Estou com alguns arquivos corompidos que acusam o seguinte erro: "ERROR DBFNTX/1010 Read error"
O arquivo consegue ser lido e gravado normalmente, porém apenas determinados registros estão com problema. Então, às vezes apenas consultar estes registros resulta no erro, geralmente apontando o índice .NTX do arquivo.
Sei que este assunto já foi tratado algumas vezes aqui no fórum, já andei pesquisando. Vi que a solução que costumam usar é através do NORTON FILEFIX. Mas onde eu posso encontrar este programa? Meu sistema roda em Linux, então existe alguma outra opção, talvez utilizando o fsck do próprio Linux?

Agradeço desde já pela atenção.

Abraços!

[Eolo]

Tive esse problema, faz muito tempo, um colega me mandou um tal de DBFDOCTOR (versáo 2-2-396). Tenho ele aqui, se quiser eu lhe mando.
Tenho também os arquivos de um site, que mostram a estrutura (em disco) de um DBF. Com ele, consegui abrir o DBF corrompido em baixo nivel (Fwrite, Fopen etc) e garimpar registro a registro. Posso lhe mandar também.

Consegui recuperar bastante coisa, mas alguns registros se perderam, tive que reconstruir (ou tentar reconstruir) na unha. O problema é que tinha campo data com caracteres alfa, por exemplo, aí não tem Doctor que dê jeito.

Esse soft não é LInux, mas se vc tiver outro PC com o Windows, pode levar o DBF pra ele e tentar a recuperação. Depois traz de volta.

Conhecendo a estrutura do DBF e abrindo ele em baixo nivel, dá pra ir lendo pedaço por pedaço, consistindo o conteúdo de cada campo e ir salvando o dados válidos em outro DBF. Depois é abrir o novo DBF com o Dbase e tentar reconstruir o que faltou.

[JoséQuintas]

Vou pelo que já passei.

1. No tempo da rede Novell 3.12, a Novell tinha um problema quando ficava no ar mais de uma semana sem reiniciar. Ela se perdia nos registros. Dava erro no APPEND BLANK. Motivo: o arquivo tinha 10 registros e ela considerava que tinha 11. Ao fazer um APPEND BLANK pra incluir o registro 12 não conseguia, porque não existia o registro 11.

2. No tempo do Windows 95/98 OSR/2000, algumas versões do Windows vinham com driver de rede ruim, que causava um problema parecido com o da Novell: retornar tamanho físico errado do arquivo. Ao incluir registro com uma máquina destas, o erro acabava aparecendo em outra máquina, por isso foi difícil detectar. Numa das vezes foi um notebook com Windows 2000.

3. No tempo do W98: Eu usava campo MEMO, e tive erro após indexar um arquivo. Retirei o campo memo e o problema parou. Era o arquivo de pedidos, indexado por número de pedido, e só porque as observações estavam em campo memo dava erro. e nem era usado no índice.

4. Nos tempos atuais: limite de arquivos da rede Windows 7 P2P.

5. Outra coisa que causa erros mas não cheguei a passar por isso: uso de 100% de CPU pelo Clipper, o que não permite ao Windows gerenciar o que precisa.

6. Ia esquecendo do básico: problemas de falha de rede, ou falha de disco, ou DISCO CHEIO (difícil mas não impossível).

7. Comum em NTX: não abrir todos os índices na mesma ordem, ou esquecer de abrir algum.

8. Index on Trim(). O índice tem tamanho fixo. Indexar com Trim() pode causar problemas imprevisíveis

9. Se não me engano, o limite do NTX pra chave é de 100 caracteres. Verifique se a sua chave passa disso.

Comece confirmando se poderia ser um destes.

Só um comentário extra:
Supondo que um arquivo DBF tenha 7 índices, isso conta como 8 arquivos abertos (1 DBF + 7 NTX)
A vantagem do índice CDX é que isso contaria como 2 arquivos abertos. (1 DBF + 1 CDX)

[trooper7]

Obrigado pelas respostas, amigos!

Eu encontrei o DBF Doctor hoje, baixei e vou tentar recuperar mais tarde usando ele.
O problema é que como o arquivo está corrompido, eu não consigo mover nem copiar ele pelo linux. A única saída que eu vejo é usar um computador com windows que está na mesma rede do servidor, mapear a unidade e tentar restaurar por ele.

Quanto às hipóteses das causas do erro, eu creio que o problema tenha sido uma pane na rede, durante o processo de gravação no arquivo, ou o problema foi no disco rígido mesmo (que inclusive já foi trocado por via das dúvidas). Algumas trilhas ficaram danificadas, portanto eu acho que tenha sido esse o motivo da corrupção nos arquivos.

Vou tentar usar o DBF Doctor, caso não funcione vou tentar reconstruir os registros na unha. Só preciso de algumas informações de como proceder com isso da maneira mais segura possível. rs

Obrigado pela atenção,

Abraços!

[alxsts]

Olá!

Já tentou criar um arquivo vazio, com a mesma estrutura do que está com problema. e fazer o APPEND FROM?

[JoséQuintas]

Tem também o filefix, acho que do Norton, pra DBFs e outros.

[trooper7]

alxsts, já tentei... porém o append funciona até o registro que está com problema, depois o próprio xprompt (pois estou usando no linux) acusa "read error". Um exemplo: o arquivo tem 70 mil registros, quando chega no registro número 42500, ele trava.

[JoséQuintas]

Lembrei de um problema onde a marca de registro excluído era trocada.
Tenta pular parte dos registros, usando GOTO n
Pelo menos se der certo, reduz a perda.

[JoséQuintas]

Não sei em que pé ficou o filefix, se foi abandonado e agora é de uso livre.
Coloquei aqui:
http://www.jpatecnologia.com.br/arquivos/filefix.zip

[alxsts]

Olá!

Tente ignorar os registros com problema. Adapte o código abaixo à suas necessidades:

Código: Selecionar todos

FUNCTION Main()

   LOCAL nFCount, nPos, oErr

   USE Teste EXCLUSIVE NEW ALIAS InFile

   DBCreate( "Recover", InFile->( DbStruct() ) )

   USE Recover EXCLUSIVE NEW ALIAS OutFile

   InFile->( DbGoTop(), nFCount := FCount() )

   WHILE .T.

      BEGIN SEQUENCE
      //Try    //para xHarbour
         WHILE InFile->( ! Eof() )
            OutFile->( DbAppend() )

            FOR nPos := 1 TO nFCount
                OutFile->( FieldPut( nPos, InFile->( FieldGet( nPos ) ) ) )
            NEXT

            InFile->( DbSkip() )

            // Interessante:

            // Se eu deixar essa linha aqui :

            // Alert( (1 / 0 )) // Dividir por zero

            // Tanto no Harbour quanto no xHarbour, usando BEGIN SEQUENCE... RECOVER... END
            // Ele faz o Alert() e não cai no RECOVER.

            // No xHArbour, Usando Try... Catch... End, ele faz certinho, cai no Catch, dá a mensagem e ignora o registro

            // Não tenho Clipper para testar com ele.

            // Não testei a sintaxe do Harbour BEGIN SEQUENCE WITH [code block]...
         ENDDO

      RECOVER USING oErr
      //Catch oErr   // para xHarbour
      
         Alert( "Registro com problema sendo ignorado. Recno(): " + LTrim( Str( InFile->( Recno() ) ) ) + ;
                Chr(13) + Chr(10) + "Dos Error :" + LTrim( Str( FError() ) ) + ;
                Chr(13) + Chr(10) + "GenCode   :" +   LTrim( Str( oErr:genCode ) ) + ;
                Chr(13) + Chr(10) + "Descrição :" + LTrim( oErr:description ) ;
              )

         InFile->( DbSkip() )

         LOOP

      END //SEQUENCE

      EXIT

   ENDDO

   DbCloseAll()
   
   RETURN NIL
//------------------------------------------------------------------------------

[rochinha]

Amiguinho,

Este problema mais parece erro fisico, problema no cluster em que esta o arquivo.

[Eolo]

Trooper, como eu fiz:

1. Rode a função HEADER() com o DBF aberto, ela mostra o tamanho em bytes do cabeçalho do arquivo. Pra Header(), não importa se ele está corrompido ou não.

2. Abra o DBF com o FOPEN() e depois use o FREAD() pra ler o danado em pedaços (você define quantos bytes ler a cada passada)
Pra FOPEN() e as outras funções de baixo nível, não importa se o DBF tá corrompido.

3. Ah, abandone a quantidade de bytes apontada pela função Header(). Dessa quantidade, pra frente, estão os dados do DBF, campo por campo. Exemplo:

[HEADER].....................“EOLO VENTURA 44556634 TRua Tal S/N Fundos 20131104OSASCO SP ANTONIO”

4. Faça o FREAD() ler cada pedaço do arquivo, do tamanho total da soma do tamanho dos campos. No exemplo acima, “li demais” e apareceu o ANTONIO, que é do registro seguinte.

5. Ajuste o valor pra ler só o tamanho de cada registro

(se a memória não tá me traindo, tem uns caracteres de controle entre um registro e outro. Inclua-os no FREAD() e depóis desconsidere na consistência - veja abaixo).

6. Agora quebre essa leitura em pedaços:
- Nome (25) - “EOLO VENTURA “
- RG (10) - “44556634 “
- T/F Cliente Bão ou Não (1) - “T”
- Endereço... etc etc.

7. Abre um DBF novo pra ir salvando as informações recuperadas

8. Agora é só pegar cada pedaço desses e consistir:
- campo DATA só pode ter números e tem que ser uma data válida. Se não for, deixa a data em branco no DBF destino. Se for válida, grava no Novo.DBF
- Campo Lógico só pode ter T ou F. Se aparecer outra, deixa em branco.
- E por aí vai...

Dá um trabalhinho, mas funciona. Eu tentei o tal DBFDoctor, gastei uns bons dias, não saí do lugar. Com o meu jeito caseiro, resolvi a parada.

[Eolo]

EM TEMPO: usando DBFDoctor ou outra opção do tipo, o que (parece) que aconteceu comigo foi que, quando o Doctor achava algum caracter de controle entre os bytes em que ele não deveria estar, ele se perdia. E Abortava. "Incapaz de continuar..."

Exemplo
[HEADER].....................“EOLO VENTURA 44556634 TRua Tal S/N Fundos 20131104OSASCO SP ANTONIO”
[HEADER].....................“EOLO VENTURA 445[chr26] 56634 TRua Tal S/N F[chr0]undos 20131104OSASCO SP ANTONIO”

[Eolo]

Anexo o treco que achei, na época, de como é um DBF por dentro.
Pode ajudar...

[Eolo]

Anexo um dump de um DBF, como exemplo.

A parte de cima é o header. Os registros começam em:
"2FORD..... 3VOLKSWAGEN BRASILIA...." etc.