PC Toledo

Ola amigos,

Uso o xharbour e aprendi aqui que fica mais rápido usar o Dbcommit() e Dbunlock(), pq eles só agem sobre o arquivo em uso, então, eu troquei tudo.

Desse dia em diante, notei que alguns arquivos (grandes) deram pra ficar com índices corrompidos, aparentemente do nada, quando isso raramente acontecia no passado, usando o COMMIT.

Li a pouco, aqui no tópico https://pctoledo.org/forum/viewto ... mit#p61959 a seguinte postagem do companheiro ALEXTS

Olá!

Se não me falha a memória, tem alguma chave do registro do Windows que interfere no DbCommit().

Gostaria de saber se estou no caminho certo, em desconfiar do Dbcommit e do Dbunlock, pq já reli todo o código e não vi nada errado...

Os meus DBFs eram NTX e eu mudei p/CDX...

Grato a todos,

Gabriel

Como já citei em outros tópicos, o cache de disco do Windows às vezes pode nos pegar de surpresa.
No uso de TEF discado por exemplo, uma das orientações é desabilitá-lo. Eu desabilito em qualquer caso.
Acredito que o problema não seja no uso do dbcommit(), pois o que ele faz é descarregar os dados da memória para o disco, em seguida os índices são atualizados com base no dbf. Agora, é preciso ter certeza de que os índices estão abertos para receberem estas atualizações.
De repente tem algum índice de fora perdendo-as.
Uma situação que pode ocorrer: Se, de repente no meio do enterro você cria outro índice condicional/temporário para atender uma situação diferente: e em seguida não deixar os dois abertos ( o índice principal e mais o segundo ) como em: as tabelas de índices ficarão desatualizadas ou seja, vão haver registros no dbf sem correspondente no arquivo de índice.
Verifique esta possibilidade, além de outras como a saúde do disco rígido, rede, etc ...

No uso de TEF discado por exemplo, uma das orientações é desabilitá-lo. Eu desabilito em qualquer caso.

E como desabilita esse "cache' no XP, Alamino ?

Ola! Bom dia!

Descobri o comando commit em meados de 1990, até então quando o micro desligava por falta de energia todos os registros que tinham sido incluídos até última abertura do dbf eram perdidos, simplesmente porque os registro ficavam guardados em cache e só eram gravados no arquivo quando o cache enchia ou os dbf's eram fechados.

Depois com a evolução do Clipper apareceu a função dbcommit() que atuava no dbf específico.

Até o momento, utilizando o dbcommit(), não tive problemas com perdas de dados ou atualização de dbf's. Hoje estou trabalho em ambiente Linux, mas tenho sistemas em produção rodando em Windows XP. Ambos sem problemas de liberação do cache para o disco rígido.

Um exemplo simples:

Um exemplo:

Amiguinhos,

Caso suspeitem do uso do COMMIT ou DBCOMMIT use SKIP após destravar o registro.

Ok, amigos.

Vou trabalhar com o Dbskip(0) em lugar do Dbcommit() e vou desbailitar o cache de disco, para ver se resolve.

Mas. acredito que o sistema deve ficar + lento, depois de desabilitar o cache de disco

Obrigado a todos,

Gabriel

Nunca precisei mexer em nada disso. Não aconselho a desabilitar o cache de disco.
Se usa o xHarbour, pode ser um bug do RDD, pois ele é copiado do Harbour e tem vários problemas de compatibilidade, segundo o Przmek.
Verifique se está acontecendo o problema em outros clientes, a rede é Wireless ? etc....

Saudações,
Itamar M. Lins Jr.

Itamar,

A rede é cabeada e minha pequena empresa é a única cliente dos meus programas. Eu desenvolvo eles para usar no pequeno negócio comercial da minha família..

Eu vou procurar algum link aqui no fórum, pra baixar e testar outra RDD (?) pro meu xharbour 1.0.0 SIMPLEX

É apenas o arquivo Dbfcdx.lib , que vc sugere que possa estar bugado e que eu devo substituir, né Itamar ?

Leia as correções, do próprio xHarbour do RDD CDX 1.0 para 1.1
Acredito que não pode atualizar somente a lib, deverá fazer updrade para versão mais nova do xHarbour.

Saudações,
Itamar M. Lins Jr.