PC Toledo

Olá!
Ainda hoje tenho probela de arquivos dbf quebrados, em alguns computadores.

Quando o usuário volta a usar o sistema percebe que tem alguns registros a mais com caracteres estranhos. As vezes são centenas de registros, daí eu tenho que apagar tudo no braço mermo.

Antes eu disconfiava que era um erro de sistema operacional, fazia um scandisk e depois um defrag, meio que enrolava os usuários.

Mas, conversando com o Eolo, fiquei sabem que ele nunca teve esses problemas e me disse ela que a solução seria criar índices sem campos repetidos pois os RDDs do clipper não gerenciam bem índices com campos repetidos.

Os campos repetidos são:
num arquivo com dois campos, código e nome;
001,JOAO
002,FRANCISCO
003,MARIA
004,JOAO
.... .....
... se eu criar um índice com o segundo campo o RDD tende a falhar e posteriormente a quebrar, logo no índice vai existir JOAO duas vezes.

Depois analizando meus arquivos quebrado, vi que todos eles tem índices com campos que podem serem iguais nos registros sequintes, tipo data de inclusão, nome do credor, código da conta no diário, etc.

Queria saber dos amigos o que vocês acham dessa afirmação do Eolo.

Ainda tô testando, mais se for verdade, ele acabou com uma dor de cabeça de longa data.

Uso o clipper 52e e índices NSX.
Grato pela atenção.

clodoaldomonteiro escreveu:Queria saber dos amigos o que vocês acham dessa afirmação do Eolo.

Felizmente não é assim. Repetições acontecem. Se fosse assim, eu não poderia ter dezenas de duplicatas vencendo num mesmo dia (chave pelo data de vencimento), como de fato tenho num cliente grande. E nunca tive problema. Aliás, nem lembro quando foi a última vez que o cliente precisou reindexar pra correção de algum problema de índice. Pode botar aí uns 2 ou 3 anos. Nesse tempo só tenho reindexado em função de alterações.

Seu problema pode estar em vários lugares, mas não no índice. Seja ele NTX, que usei por muitos anos (com registros indexados repetidos também) sem qualquer problema, ou CDX, NSX (o que uso), etc.

O difícil é saber onde está a verdadeira raiz do problema. Principalmente sem analisar seu código, sem conhecer em que condições de hardware seus programas são executados, sem saber como o usuário se comporta, etc.

Eu sempre achei que fosse problema de máquina, mas nunca pude provar isso.

O sistema funciona em cima do windows 98 com pcs de todos os tipos desde processadores cirix a P4, ou seja pcs velhos e novos, são uns quarenta computadores, mais só acontece em uns 4 ou 5 pcs, nunca ao mesmo tempo.

Tem um cliente que teve esse problema, ele usava um pc bem antigo, quando ele mudou para um p4 com XP, ai nunca mais teve esse problema.

Só sei que é um mistério, e não tem nada pior do q não saber o que é q tá acontecendo.

Clodoaldo, seu sistema está em rede então ? Qual seria o servidor WINXP ou WIN98 ?. Acontecem travamentos, na rede ?. Está utilizando o DBCOMMIT() ou DBCOMMITALL().

# Corrigido "N"

Se você já sabe quais são os 4 ou 5 computadores em que isso acontece, fale para o cliente isolá-los. Pelo menos por um período de teste, pra comprovar sua suspeita. E se ela se confirmar, jogue gasolina neles, bote fogo e mande o cara se virar.

E pode muito bem ser hardware. Mas nunca índice com entradas duplicadas. Pelo menos nisso o Clipper é inocente.

Pablo César escreveu:DBCOMMINT() ou DBCOMMINTALL()

Eu não tenho essa biblioteca. É de menta? ))))))

KAKAKA essa foi boa ! Só menta ou mentol para aquela função... hihihi

Sorry. Ja corrigí na msg. Você Maligno me ensina português e eu te ensino ingréis, tá legal ? (já viu os vídeos em piadas ?)

Pablo!
Os sistemas são windows 98, os pcs são diversos e de idades variadas.

O servidor eu acho que é NT, mas eu não uso ele para armazenar dados, eu instalo o sistemas em todas as máquinas, menos o servidor, cada equipe de contadores tem 2 pcs, ai a base de dados fica em um pc que é compartilhado e faço um mapeamento no outro, para acessar a base de dados, sendo que todos os pcs podem acessar uns aos outros, o servidor serve somente para gerenciar a rede.

Malígno!
Tem máquina que tem menos de 1 ano. Mas eu sempre boto culpa nelas e na falta de operador de rede que fique lá todo tempo.

Amiguinhos

Quais situações voce acham que podem fazer com que um .DBF comece a aparecer com lixo gravado, mas não corrompido?

Bom, recentemente, analisando .DBFs em um cliente vi que alguns .DBFs com muitos registros estavam com sujeiras em varias partes do mesmo e ai é que o bicho pega, voce começa a desacreditar do banco de dados.

Bem fiz o seguinte:

- Abri um dos .DBFs através do meu utilitário preferido( DBFViewer2000 ).
- Naveguei pelos registro até encontrar o lixo.
- Organizei esta visualização por um dos campos chaves deste .DBF e encontrei o lixo no inicio e no final daquele conjunto de dados.
- Organizei novamente, agora usando outro campo que uso como chave e pronto, la estavam a lixarada, no inicio e no final dos dados.

Que M****...

Percebi que o lixo era gravado junto com os dados, talvez no momento de um commit(), no inicio e no final do conjunto de dados, na ordem em que estavam selecionados no momento.

Explicando melhor:

Tenho um .DBF chamado CLIENTES ordenado pelos campos CODIGO e NOME.
Ao abrir esta tabela os dados estão ok, começo a navegar e de-repente vejo, lixo.

Se eu organizar os dados pelo campo CODIGO, encontro o lixo no inicio e no final.
Se eu organizar os dados pelo campo NOME, também encontro o lixo no inicio e no final.

Desta forma fica mais facil saber como e o que limpar.

Encontrando um culpado

Navegando pelos registros contendo lixo e olhando o conteudo que ali esta, consigo identificar uma palavra:

Avast

Conclusão

O Avast pode até proteger sua maquina, mas tenho a prova de que o mesmo pode também deAVASTar o conteudo de meus .DBFs.

Portanto não ponha ainda a culpa nos PC´s velhos e Windows 98s da vida sem antes verificar se o seu antivirus não é o culpado por toda a M**** encontrada.

Na minha opinião

Usando o Norton corporate Edition, que apesar de ser 50% mais leve que o Norton tradicional nunca me causou problema deste tipo.

Em suma, boa sorte, porque eu também tenho de limpar o lixo que esta nos .DBFs do backup de meu cliente.

Rochinha!
É exatamente isso que acontece comigo, só que os meus clientes, na grande maioria usam o AVG.

Com essa sua dica, vou verificar se aparece o nome do ant-virus.

se esse lance de índice fosse verdade nenhum sistema do mundo feito em clipper estaria funcionando....

quanto ao lance do anti virus nao sei dizer, mas na dúvida vou apagar todos os registros que tenham alguma cara chamado NORTON rsrsrsrsrs

Na minha experiência percebi que só ficam quebrados os DBFs se o cliente fechar o programa pelo botão fechar ou pela opção Fechar do Menu de Controle da Janela. Mas, depois que desabilitei isso, com a ajuda da biblioteca WAPI do Maligno parece que isso deu uma parada.
Também, a cada 3 minutos, se ficar parado num menu de prompt, o programa fecha todos os arquivos e os reabre. Isso , para mim, faz com que todo o buffer seja descarregado no HD.
Aí melhorou 100%.
Mário

Nunca fiz o teste, mas só com o dbCommitAll() já deveria ser suficiente para não se perder nada. Não dá pra saber se é igual a isso, mas num sistema de "flushing" antigo que vi certa vez, apenas se usava um serviço do DOS que duplica um manipulador de arquivo. O efeito disso é o "flush". Isso equivale a fechar e abrir o arquivo de novo. Se o dbCommitAll() faz isso (infelizmente, não dá pra saber), torna desnecessário o procedimento extra de fechar e abrir novamente.

Ainda continuo esperando acontecer de novo, e quando acontecer mostrarei todos os dados, desde de o pc até os arquivos e índices.

Ok. Havendo algum dado novo a respeito, entre em contato.