PC Toledo

Bom dia,

Estou tendo dor de cabeça com indexes, e estou precisando aumentar melhorar a segurança, pelo menos não iniciando o programa se iver indexes corrompidos.

O programa está Ok, mais é problema com usuários??

Existe umas funcoes que verificam a integridade dos indexes, quando voce abre o DBF, se não me engano os nomes são "VALIDNTX e VALIDDBF" no meu caso estou usando .CDX ??

Saberiam onde posso encontra-las??


Grato.

Olá meu caro,
1º - Não seria melhor reindexar na 1ª Execução, ao invés de verificar integridade ?
2º - Em se tratando de .CDX, não se esqueça de apagar os arquivos antes de reindexar, senão ele vai crescendo, crescendo...e vira uma
3º - Na hora de abrir os indices,mudar de tag, abuse das funções ao invés dos comandos (elas são muito mais seguras)
veja só:

ao invés de SET INDEX TO
use DBSETINDEX("INDICE")

ao invés de SET ORDER TO TAG ordem
use ORDSETFOCUS("ordem")

Ok ?

"VALIDNTX e VALIDDBF"

exitem estas funcoes

se existirem, gostaria muito de utiliza-las em meus sistemas.

desde já agradeco

Pois é, a principio não questionei, mas já que o nosso amigo Filizola também achou estranho.... :|

Cezar,

No CDX, qdo vc usa INDEX ON... TAG... ele joga a TAG no fim do arquivo e este vai aumentando, sim. Mas qdo vc usa REINDEX, os TAGs são reconstruídos e o espaço não utilizado é eliminado (como se fosse um "pack"). Então, se usar o REINDEX não precisa apagar o CDX antes.

Quanto aos índices corrompidos, é o seguinte: a indexação presupõe que cada registro seja ÚNICO; quando não é, a indexação é até feita, mas depois, durante o uso (inclusão, exclusão, alteração), começa a dar pau. Dê então uma conferida nas chaves que vc usa, confirmar que são "únicas".

Eu já passei por isso, um arquivo Vendas com um dos índices só pelo código do cliente. Como o mesmo cliente tinha "n" vendas, a chave não era única e uma hora a Clipper se perdia, resultando no "corruption detected". Resolvi o problema mudando a chave. Como não tinha outro campo, passei a usar, o invés de "index on codigo", "index on strzero(codigo,5,0)+strzero(recno()).

Outra coisa: se uma data fizer parte de uma chave, converta ela com o DTOS() e não use alltrim() ou rtrim() em campos C: as chaves, além de únicas, devem ter o mesmo tamanho.

Eolo

Desculpe caro amigo Eolo, mas, quanto ao problema de indices corrompidos,
sou obrigado a discordar, trabalho com eles há alguns anos, e tive alguns problemas por estar usando comandos em vez de funções, mas fora isso, sempre funcionou 100%.
Tenho uma rotina de pedidos como vc mencionou, e tanto faz o clientes ter 1 ou n pedidos, os indices nunca deram pau. Com certeza seus indices quebraram por outro motivo.
Agora, caro amigo Cesar, não esqueça de incluir além de DBFCDX.LIB o _DBFCDX.LIB.

Alamino,

O que eu disse e reafirmo, é que o princípio da indexação pressupõe que a chave seja única. Se isso não fizesse sentido, vc, eu e o Cezar poderíamos ter o mesmo CPF; aí, quando vc desse um seek no CPF do Cezar, o Clipper saberia achar exatamente o CPF do Cezar, e não o meu ou o seu... (Como?).

Disse também, e reafirmo, que o Clipper até faz a indexação com chaves não-únicas, mas com a movimentação do arquivo DBF ele pode acabar se perdendo, resultando no "corruption detected" (afinal, porque esta mensagem existe?).

Agora, o CDX pode ter algum mecanismo (eu desconheço) que faça com que um arquivo de 1 milhão de registros, com uma chave idêntica em todos, seja indexado corretamente, sem se perder (embora eu não perceba a razão de se indexar esse 1 milhão de registros se as chaves são iguais...). Se vc souber como isso funciona, eu gostaria de aprender!

Abraço.

Eolo

Agora captei a sua mensagem, porém indexar usando Index on str(codigo)+str(recno()) é um pouco vago, não acha ?
Não seria melhor Index on Str(Codigo)+Nome ?
E continuo reafirmando, essa não é a causa do Corruption Detected.

Alamino,

Se a chave de indexação é única, beleza. Agora, se o seu arquivo tem por ex só o campo CPF (meio absurdo este exemplo!) e todos os 500 mil registros têm o mesmo número CPF...

O recno(), então, é a saída. E não é meio vago, não, muito pelo contrário. Como obviamente não existem 2 recno() iguais em um DBF, se você indexar os 500 mil registros com o mesmo CPF (1234, por ex) usando "CPF+strzero(recno(),12,0)" cada um vai ter uma chave única, ou seja:
CPF_recno()
1234_000000000001
1234_000000000002
1234_000000000003
etc.

Quanto ao "corruption detected", qual é então a causa dele?

Eolo

Realmente é inteiramente absurdo ter um banco só com CPF´s e mais nada !
Agora as causas do Corruption Detected podem ser por exemplo:
1º - No começo eu linkava meus prg´s só com DBFCDX.LIB > causava este erro
2º - Depois acrescentei _DBFCDX.LIB > resolveu bastante coisa

3º - Não usar aquela historia de Index on codigo for ou while ....
e sim usar Set Scope to .... Essa aqui é o bicho !!!

4º - Usar funções em vez de comandos, pois o pré-processador pode interpretar as coisas meio pela metade ou do jeito dele.

Com tudo isso Eolo, meu sistema nunca mais deu problema de indices.
Se discordar em algum ponto, poste que vamos continuar...
Um abraço

Alamino,

Legal, vamos nos falar sim! Conversando a gente troca experiências e aprende.

Bem, vc explicou o que usa, mas não explicou o que causa ou o que é o "corruption detected"... (eu, uso comandos e NTX na maioria dos meus programas, Clip52c+Blinker50, Win98/ME/XP, em rede ou não, e a estabilidade é também 100%).

(lembra do famigerado erro 8002 - Clip53+Exospace+Optedit - na criação de indices para arquivos DBF grandes? Eu abandonei a trinca, não vi nenhuma explicação que resolvesse a parada. Passei a usar o Clip52+Blinker50 com os mesmíssimos fontes e DBFs, o problema nunca mais apareceu...)


Bem, até onde eu vi e experimentei, o "corruption" acontece tanto em arquivos DBF quanto em arquivos indice. Nos dois, uma falha de software ou hardware ou energia, por ex, pode causar a gravação de dados sem sentido, como por exemplo letras num campo data do DBF ou a atualização não completada de arquivos índice. Numa próxima rodada, o Clipper não vai saber o que fazer no próximo USE com "ANTONIO SI" no campo data, e dá o "corruption detected"...

Ou, se um DBF tem por ex 100 registros, vc adiciona 1 registro sem ter os índices abertos, depois abre ele novamente com os índices... O Clippper não vai conseguir abrir o DBF com 101 e o índice com 100 registros... "Corruption detected".

No caso da tal "chave única", li (não lembro mais aonde) que o "curruption" acontecia pelo seguinte (com o NTX): na indexação, o Clip pega o reg1 e marca ele como chave1. Pega o reg2, vê qual a ordem de indexação, e digamos marca ele como chave1, passando o reg1 pra chave2. E assim por diante. Só que, se vc tem muitos "regs" iguais, chega uma hora que Clip não sabe mais qual chave usar para o reg "n", já tem um monte de regs iguais, aí ele "se perde"... E aí aborta, com o "corruption detected".

Resumindo, talvez o CDX tenha alguma coisa melhor que o NTX, cuidando desses registros de mesma chave... E é isso que quero aprender.


Quem sabe vc, que usa o CDX, poderia fazer um teste: criar um arquivo DBF só com um campo NOME, mandar indexar ele por esse campo NOME e ir appendando registros, todos com conteúdo igual ("Corruption Detected", por ex... eheheh). Tipo 500.000 registros. Aí, se não abortar durante, dar um dbseek() em "Corruption Detected" para ver onde o pointer pára...

Eu já fiz isso (com o NTX) e adivinha o que deu?! Bingo. Por isso, hoje, forço para que as chaves sejam únicas (inclusive com o uso do recno() onde for preciso).

Abraço.

Eolo

Eu tive este problema de indices corrompidos quando usava indices condicionais (index on ... tag... while ou for ... to indice), onde já existia um indice ativo, e dois ou mais usuarios indexassem condicionalmente, mesmo NÃO havendo alterações no registro.
Agora sobre o que vc mencionou:
Ou, se um DBF tem por ex 100 registros, vc adiciona 1 registro sem ter os índices abertos, depois abre ele novamente com os índices... O Clippper não vai conseguir abrir o DBF com 101 e o índice com 100 registros... "Corruption detected".
{O Clipper simplesmente não vai encontrar o registro, só isso.}

depois:
No caso da tal "chave única", li (não lembro mais aonde) que o "curruption" acontecia pelo seguinte (com o NTX): na indexação, o Clip pega o reg1 e marca ele como chave1. Pega o reg2, vê qual a ordem de indexação, e digamos marca ele como chave1, passando o reg1 pra chave2. E assim por diante. Só que, se vc tem muitos "regs" iguais, chega uma hora que Clip não sabe mais qual chave usar para o reg "n", já tem um monte de regs iguais, aí ele "se perde"... E aí aborta, com o "corruption detected".
{Voce quer dizer que o Clipper tem um BUG ?}

Simplesmente Eolo, tudo o que vc relatou, comigo nunca aconteceu, estranho, o Clipper sempre trabalhou redondo, a não ser quando faço alguma besteira.
Será que estamos linkando da mesma forma ?
Usando as mesmas lib´s ?
Complicado ...

Cara, acho que descobri a besteira que to fazendo!
Eolo

Poste que vamos encontrar a solução :)Pos

Ola,


Conversei com um amigo e ele me lembrou que o codigo destas funçoes estão no livro "CA-CLIPPER 5.2 EM REDES"

Vou procurar, mas se alguem achar, de um toque e poderemos testar e aliviar as dores de cabeca com indexes.



Grato.