PC Toledo

Boa noite a todos.

Trabalho numa empresa de consultoria em informática, e temos um cliente com o seguinte problema: os acompanhamentos, que são armazenados em um arquivo dbf (utilizando campo memo e índice cdx) estão sendo perdidos. Segundo o cliente, os acompanhamentos cadastrados diariamente muitas vezes desaparecem no dia seguinte. Já foram tomadas as seguintes medidas, sem resultado efetivo:

1) reduzir o tamanho dos arquivos: anteriormente, o DBF tinha 27 MB e o arquivo FPT tinha 50 MB (cerca de 367.000 registros). Após eliminarmos vários clientes inativos, o DBF passou a ter 19 MB e o FPT 28 MB (cerca de 250.000 registros).

2) o arquivo DBF foi recriado e os registros re-importados.

3) o SET CLIPPER foi revisto em todas as máquinas, constando com a seguinte configuração: SET CLIPPER=//F:200 //DYNF:8 //SWAPK:65535 //SWAPPATH:"C:\TEMP" //TEMPPATH:"C:\TEMP" //E:0

4) Nos pontos de gravação foi utilizada a seguinte estrutura:
RLOCK()
DBSKIP(0)
REPLACE...
DBCOMMIT()
DBRUNLOCK(RECNO())

5) Solicitei que me informassem todas as vezes em que ocorresse alguma mensagem de erro, mas até agora não me informaram nenhuma ocorrência de Corruption Detected ou Internal Error, pelo menos no decorrer deste mês. Em relação ao passado, eles não souberam me informar se estas mensagens já haviam ocorrido.

Gostaria de saber se existe alguma outra medida que poderia tomar, no sentido de sanar o problema acima relatado. Agradeço antecipadamente a atenção dispensada.

Clarice.

Bem Vinda ao Forum...

1) reduzir o tamanho dos arquivos: anteriormente, o DBF tinha 27 MB e o arquivo FPT tinha 50 MB (cerca de 367.000 registros). Após eliminarmos vários clientes inativos, o DBF passou a ter 19 MB e o FPT 28 MB (cerca de 250.000 registros).

Tamanho não dah problema de Corruption, não sei com grandes quantidades como 3 ou 4 Milhoes...de registro....

2) o arquivo DBF foi recriado e os registros re-importados.

Otimo Passo....o seu DBF poderia esta corrompido mesmo...

3) o SET CLIPPER foi revisto em todas as máquinas, constando com a seguinte configuração: SET CLIPPER=//F:200 //DYNF:8 //SWAPK:65535 //SWAPPATH:"C:\TEMP" //TEMPPATH:"C:\TEMP" //E:0

Como vc falou em todas as Maquinas entaum...esta em rede neh.....claro...bom vc jah usa os tratamento para rede em clipper ?
de uma olhada no link abaixo:
http://www.caclipperwebsite.com/howto/topico01.htm

Obs: Vc abre todos os indice desse DBF cada vez que altera ou cria algo nele ?.......até onde eu sei...vc deve abrir.

Gostaria de saber se existe alguma outra medida que poderia tomar, no sentido de sanar o problema acima relatado. Agradeço antecipadamente a atenção dispensada.

Desculpa, mas eu não uso campo MEMO e não tenho problema com Corruption Detected....então tudo que vc citou era o que eu poderia lhe dizer....

Abraços
Leonardo Machado

Particularmente, nunca usei campos MEMO em 18 anos de profissão. Nunca achei esse tipo de campo confiável. Mas já precisei resolver situações como essa sua, de armazenar textos. O que fiz e faço desde o começo, é usar uma lista ligada, que funciona de forma bem simples. E nunca tive qualquer tipo de problema. Esta é uma boa forma de sanar o problema.
Para o seu caso seria uma mudança bem radical. Ainda assim, é um esquema de trabalho realmente simples e pra curto prazo, digamos assim.

Pra longo prazo, o melhor caminho é realmente abandonar os DBFs. Mas não vou entrar no mérito dessa questão, senão esse tópico vai longe. Até porque, não foi isso o que você perguntou.

Clarice,

RLOCK()
DBSKIP(0)
REPLACE...
DBCOMMIT()
DBRUNLOCK(RECNO())

Quanto aos comandos:
a) primeiro, precisa checar se o RLOCK() funcionou: se ele retornar .T., o registro foi bloqueado e se pode ir em frente; se retornar .F., tem que abortar a gravação...
b) o DBSKIP(0) está a mais. A única razão de se usar isso é pra tornar uma alteração visível a outras estações da rede. Mas, se o REPLACE ainda não foi dado, pra que o DBSKIP? Por mim, elimina-se esta linha, até porque tem o DBCommit() depois. Ainda, quem sabe esse SKIP não tá bagunçando o RLOCK()?
c) como vc faz o REPLACE? Mostra ele pra gente.
d) o próximo é DBUNLOCK() e não DBRUNLOCK(), certo? Não entendi o porquê do recno() como argumento. Não precisa, já que o ponteiro está sobre o registro que havia sido LOCKado.

Amiguinha

Na verdade quando voce exclui registros no .DBF os vinculos existentes nos .DBT/FPT nao sao refeitos.

A forma mais facil de compactar um .DBT/FPT é abrindo o .DBF e fazendo um COPY TO, pois os registros deletados nao serao enviados e os MEMOs ainda OK serao copiados e o arquivo refeito.

Outra coisa,

Se voce estiver usando seu sistema em uma rede e o mesmo possuir uma versao de Windows com limite de tamanho de arquivo isto pode ser um problema.

Algumas versoes do Windows como 95 e até 98A possuem um limite de tamanho de arquivos, ou seja, se o arquivo ultrapassar 2 gigas isto pode corrompe-lo.

Exemplo:

Voce tem uma rede com servidor XP, vários clientes 98 SE e um cliente 98A e alguns .DBFs gigantescos. No momento que este 98A abrir um destes arquivos, baubau.

Os numeros acima e tamanhos eu tirei de cabeça e nao me baseei em um teste real, mas ja aconteceu comigo.

Agradeço a todos pelo auxílio. Estou analisando as recomendações feitas, e assim que tiver alguma novidade estarei lhes informando.

Grata,

Clarice.

Alguém me disse, pela longa estrada da vida do programador, que este problema está mais relacionado com o tipo de índice a ser utilizado.

Você utiliza índices .NTX ?

Se sim, migre para .CDX.
Abraços
Mário

Ola Clarice...

Pelo modo de como vc efetua sua gravacao, parece que vc esta sobrepondo registro, talvez por isso haja perda de informacao ou seja uma nova informacao sobrepondo uma ja existente, haja visto que para incluir um registro utiliza-se, por exemplo DBAppend() e nao rlock(). Na sua citacao nao ha indicio de que vc esteja incluindo registro.
Se realmente some informacoes e ninguem sabe porque, sem mensagem nenhuma, sugiro que crie um arquivo auxiliar sequencial (sem indice) com um cpo para guardar uma sequencia tipo 1,2,3,4 etc e com uma informacao que vc grave que caracterize a gravacao do outro arquivo (nome, cod, etc...) que supostamente esta sumindo e se possivel guarde o recno() dele tb. tente se possivel gravar a seq gerada no arquivo que esta sumindo a informacao para se poder quem sabe mais tarde, fazer uma relacao entre um e outro
Para que isso ? Se alguem reclamar que sumiu informacao neste arquivinho estara registrado. A sequencia 1,2,3...sugiro que vc utilize um contador numa variavel que vc salve com o comando 'save all like nome.da.variavel to nome.do.arquivo' para disvincular que se utilize o conceito do ultimo registro +1.
Se isso conseguir te ajudar a solucionar o problema ai vc ranca tudo caso contrario acredito que ninguem vai mais reclamar que sumiu informacao.
Boa sorte.