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.
Problemas com perda de dados
Moderador: Moderadores
-
sygecom
- Administrador
- Mensagens: 7131
- Registrado em: 21 Jul 2006 10:12
- Localização: Alvorada-RS
- Contato:
Bem Vinda ao Forum...
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.
Abraços
Leonardo Machado
Tamanho não dah problema de Corruption, não sei com grandes quantidades como 3 ou 4 Milhoes...de registro....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).
Otimo Passo....o seu DBF poderia esta corrompido mesmo...2) o arquivo DBF foi recriado e os registros re-importados.
Como vc falou em todas as Maquinas entaum...esta em rede neh.....claro...bom vc jah usa os tratamento para rede em clipper ?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
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.
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....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.
Abraços
Leonardo Machado
Leonardo Machado
xHarbour.org + Hwgui + PostgreSql
xHarbour.org + Hwgui + PostgreSql
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.
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.
[]'s
Maligno
---
Não respondo questões técnicas através de MP ou eMail. Não insista.
As dúvidas devem ser postadas no fórum. Desta forma, todos poderão
se beneficiar das respostas.
---
Se um dia precisar de uma transfusão de sangue você perceberá como
é importante a figura do doador. Procure o hemocentro de sua cidade e
se informe sobre a doação de sangue, plaquetas e medula óssea. Doe!
Maligno
---
Não respondo questões técnicas através de MP ou eMail. Não insista.
As dúvidas devem ser postadas no fórum. Desta forma, todos poderão
se beneficiar das respostas.
---
Se um dia precisar de uma transfusão de sangue você perceberá como
é importante a figura do doador. Procure o hemocentro de sua cidade e
se informe sobre a doação de sangue, plaquetas e medula óssea. Doe!
Clarice,
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.
Quanto aos comandos:RLOCK()
DBSKIP(0)
REPLACE...
DBCOMMIT()
DBRUNLOCK(RECNO())
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.
-
rochinha
- Administrador
- Mensagens: 4664
- Registrado em: 18 Ago 2003 20:43
- Localização: São Paulo - Brasil
- Contato:
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.
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.
OPS! LINK QUEBRADO? Veja ESTE TOPICO antes e caso não encontre ENVIE seu email com link do tópico para [url=mailto://fivolution@hotmail.com]fivolution@hotmail.com[/url]. Agradecido.
@braços : ? )
A justiça divina tarda mas não falha, enquanto que a justiça dos homens falha porque tarda.
@braços : ? )
A justiça divina tarda mas não falha, enquanto que a justiça dos homens falha porque tarda.
Re: Problemas com perda de dados
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.
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.