PC Toledo

Para evitar problemas com indices corrompidos (acredite, essa técnica é muito instável) eu costumo fazer o seguinte.

Indexo o ARQ2 por nome.
Indexo o ARQ1 por código + dtos(data)
Pesquiso o nome e procuro pelo código no ARQ1.
Assim, todas as ocorrências do "cliente" serão listadas. Por ordem de nome e dentro dele, por ordem de data.
Isso evita que alteração no nome do "cliente" corrompa o indice do ARQ1.

Vamos pegar um exemplo que todos entendem:

Tenho um cadastro de produtos com os campos código e descrição.
Tenho tb um cadastro de movimentação, com código do produto e data da movimentação.
- Eu ordeno produtos por nome;
- Pego o primeiro produto e procuro pelo código qual o primeiro movimento dele;
- Imprimo todos os movimentos desse produto (dá até para filtrar por data, etc)
- Pego o próximo produto e executo o mesmo procedimento;
- Assim eu tenho o relatório dos produto por ordem de nome, dentro do produto, todas as movimentações por ordem de data.

Ufa! Acho que acabei de explicar! (ou ferrar de vez!)

Boa sorte. Espero ter ajudado.

boa tarde !

Não é bem isso que estou precisando. Tenho dois arquivos com as seguintes estruturas:

Arq1

Codigo N 6
Data D 8


Arq2

Codigo N 6
Nome C 60


O Arq1 é um arquivo de documentos:

Codigo -> codigo do documento
Data -> data que o documento foi feito


O Arq2 é um arquivo onde ficam os nomes das pessoas que figuraram em cada documento:

Codigo -> Codigo do documento
Nome -> Nome da pessoa

Os dois arquivos estão relacionados atraves do campo Codigo.

Indexei o Arq2 por Nome + Dtos(Arq1 -> Data)

Preciso abrir o Arq2 em um Dbedit() por exemplo em ordem de Nome e dentro do nome por ordem de data para que o usuario visualize os nomes por ordem alfabetica + data que o documento foi feito. Isso sem precisar gravar o campo Data em cada registro do Arq2.

Ademir,

Eu usei o SET RELATION em casos parecidos com o seu e só me dei mal... No fim, parti para uma solução (que eu uso até hoje) que, se não é a mais técnica, resolveu o problema:

Arq1
Codigo N 6
Nome C 60
Data D 8

O único cuidado a tomar é, se houver alguma alteração no cadastro (Arq2), correr o Arq1 inteiro e fazer as substituições dos nomes alterados.

Olha, eu confesso que relutei, mas relutei... pois acadêmicamente essa sugestão é um crime... hahaha (brincadeira). Mas entendo você Ademir que prefere não criar redundâncias, mas há vezes que isso compensado com o tempo de processamento, vale a pena investir. E sabemos que problema de espaço, isso não é mais tão importante assim (deve ser avaliado). Mas o que o colega Eolo diz pode vir te trazer maior agilidade, principalmente quando seu sistema é executado em computadores velhos (não desmerecendo você Eolo, hihihi), não mas sério acho que se seu procedimento funcionou e não traz demora na execução pois então o tópico alcançou seu objetivo. Cabe nos dizer se o seu método Ademir, não está causando certa lentidão (inclusive considerando esse SET RELATION, que é um pouco inconveniente a vezes).

SET RELATION, que é um pouco inconveniente a vezes

Um pouco? Dependendo da situação é MUITO inconveniente. ))

Sabe Maligno... eu até re-editei a mensagem corrigindo a minha expressão para não ser tão extremista assim. Mas seria melhor evitá-lo, se puder.

...seu sistema é executado em computadores velhos (não desmerecendo você Eolo, hihihi)...

Velho? Po, nem tenho cabelo ainda!!!!!!!!!!!!!!!
))))))))))

PS. SET RELA? Nunca mais.

PS. SET RELA? Nunca mais.

Esse SET RELATION, pra mim, está quase na mesma categoria dos smiles animados. ))

para não ser tão extremista assim. Mas seria melhor evitá-lo, se puder.

Mas se a coisa não presta, não tem porque não meter o pau devidamente. Não vejo absolutamente nada que não possa ser feito de forma alternativa ao SET RELATION. Prefiro então evitar. E meter o pau, claro. ))

Valeu pessoal! Mesmo assim vou tentar resolver o problema usando set relation. Darei noticias se funcionar.

Um abraço a todos.

Claro que, se você acha que SET RELATION é uma boa alternativa, vá em frente.