PC Toledo

Senhores,

Fiz uma rotina para limpar dbf´s com zap e tem algumas tabelas com campo memo. O zap não está limpando o arquivo dbt, tem alguma solução pronta para resolver isso?
Não é o caso de conversão para cdx.

zap não está limpando o arquivo dbt, tem alguma solução pronta para resolver isso?

Liberte-se do campo do tipo memo. Transforme tudo em arquivos independentes em txt.

Pois é Pablo,

Bem que eu queria, mas são tabelas de sistema corporativo da prefeitura da cidade do rio de janeiro, entede a encrenca?
Estamos fazendo envio de tabelas para terceirizados fazerem um pesquisa de campo e não tem como remover estes campos memos.
Desde já agradeço.

Olá!

Não tenho como testar agora mas, tente abrir cada arquivo e fazer um COPY STRUCTURE para outra pasta. Verifique se ele cria o .DBT vazio.

Abre o arquivo com o DBU por exemplos.
tecle F3 pra criar/alterar estrutura e depois grava !
isso vai fazer com que seu DBT fique ok.

Lucimauro e Alxsts,

Obrigado pelas dicas, Lucimauro o procedimento que você sugeriu funciona, acontece que é um processo automático, a solução do Alxsts pode resolver este problema.
Obrigado a vocês.
[]´s

Amigo Pablo,

Porque não utilizar campos memo nos dbfs?

Eu utilizo e nunca notei problema algum, pode nos dar mais informações

abraço,

Puxa eu ja tive algumas dores de cabeças bem no início, principalmente na hora de restruturar os bds. Mas graças a essa minha concepção em não mais utilizar campo do tipo MEMO, nunca mais tive problemas algum. Ao contrário, funciona mais rápido, mais enxuto e mais fácil na manutenção. Este tema eu ja falei muitas vezes. Se quiser saber como substituir os campos MEMOs por arquivos independentes, veja nestes tópicos:

https://pctoledo.org/forum/viewto ... 398#p17337
https://pctoledo.org/forum/viewto ... 231#p26231
https://pctoledo.org/forum/viewto ... emo#p67840

Precisar de mais algum esclarecimento, estou a disposição. Mas eu não penso duas vezes quanto a isso. Pois armazenar os arquivos textos numa pasta ou até mesmo em subpastas, agrupadas por centenas de arquivos podem ser a melhor solução para substituir os memos. E fora que se você precisar mudar de RDD, não irá precisar se preocupar com esses arquivos, pois são arquivos textos.

Bem, cada caso é um caso.
Um campo memo fpt, é bem superior a um simples arquivo texto.
Podemos armazenar em campos FPT qualquer tipo de arquivo inclusive musicas e fotografias.
Sem falar na falta de organização de ter um HD com milhares de arquivos textos, mesmo que em subpastas, sabemos que o desempenho do HD diminui à medida que aumenta a quantidade de arquivos. E se for no windows pior ainda.

Saudações,
Itamar M. Lins Jr.

Um campo memo fpt, é bem superior a um simples arquivo texto.
Podemos armazenar em campos FPT qualquer tipo de arquivo inclusive musicas e fotografias.

Interessante, eu sabia que existia bd que comportavam imagens mas não sabia que o FPT faz isso. Só não sei se ele faz isso bem.

sabemos que o desempenho do HD diminui à medida que aumenta a quantidade de arquivos. E se for no windows pior ainda.

Concordo com isso, mas por isso antes de planejarmos o projeto é importante considerar: "cada caso é um caso". No entanto ainda sigo pensando que para o HD ser afetado pela quantidade de arquivos e por outro lado pela quantidade de espaço: creio na MMO que seria quase o mesmo. Sem considerar que: o bd também ficaria super-inchado e consequentemente fica mais lento dentro do sistema.

Parece que é uma desorganização terrível armazenar arquivos ainda que do tipo texto, mas acredite: a vantagem de desmembrá-los do BD chega a ser louvável. Pense apenas neste exemplo:

- Você implementou no seu sistema que em lugar dos campos memos, o seu sistema iria criar arquivos textos individuais para cada registro de clientes. Claro a vinculação, como eu ja disse em tópicos anteriores, tem a nomenclatura do arquivo relacionada com o número do cliente, pode ser até o cpf do cliente (mas aqui teria que ser implementado a questão dos nomes longos).
- O usuário abre eventualmente, não sempre (imagino eu) uma observação do cliente e digita o seu texto, podendo até ocupar um enorme carga de volume na sua redação. E esses arquivos são gravados obecendo um critério certo para o armazenamento (localização e nomenclatura).
- Um bom dia (por não dizer péssimo dia), o bd dá algum tipo de problemas. Não que isto possa a ser comum e que há certezas de que sempre poderá ocorrer, mas é bom levá-lo em consideração. Aí o analista passa a tomar suas medidas de "recuperação" do bd afetado e os registros fragmentados foram de vários clientes com observações. Bom a má noticia é que o usuário terá o trabalho de refazer os registros ou melhor dito incluir os clientes afetados novamente (claro com o mesmo código de cliente e "porsupuesto" cpf dos mesmos) e a boa noticia: os arquivos textos (observações do cliente) continuam numa boa (dificilmente arquivo textos, são fragmentados), eu particularmente nunca vi.

Mas enfim, cada um obedece a sua consciência. A minha é de pura tranquilidade e na intenção de passar isso para mais alguém. Não quero desmerecer ninguém com opinião contrária a minha. Apenas dou a minha concepção desse critério.

Nos arquivos DBT e FPT sempre ficará um "lixo" quando o registro do DBF é apagado.
Eu faço assim:

Ola!

Nos arquivos DBT e FPT sempre ficará um "lixo" quando o registro do DBF é apagado.

Não com a nova função DBDROP() ela apaga os indices(CDX/NSX/NTX...) e os DBT´s/FPT´s se existirem.

Saudações,
Itamar M. Lins Jr.

Itamar,
O objetivo é zerar o conteúdo do campo memo e não apagar o arquivo memo associado.

Não com a nova função DBDROP() ela apaga os indices(CDX/NSX/NTX...) e os DBT´s/FPT´s se existirem.

Olá pessoal!
A maneira mais fácil de ´zapear´ um DBF com DBT é: Acho que é isso!
T+
Euclides

O objetivo é zerar o conteúdo do campo memo e não apagar o arquivo memo associado.

É?
Pelo exemplo que ele colocou eu não vi isso não.
Outra coisa é que o Harbour não herda alguns bugs do clipper não.
A forma mais segura sempre será copiar o DBF para outro com "set deleted on"

Saudações,
Itamar M. Lins Jr.