PC Toledo

Boa tarde, em exatamente um ano fiz a migração dos indices NTX para CDX, pois estava muito lento. O ganho em rapidez foi excelente, porém ficou alguns efeitos colaterais. Na tentativa de alterar o arquivo DBU FoxPro, ou seja, alterar tamanho e insirir outros campos, o mesmo gera esse erro: Acabei desistindo de usar o DBU e comecei a usar o OURXDBU que vinha funcionando até o momento, mas começou a dar erro de corropção em alguns DBFS. A pergunta é o seguinte: Como eliminar o erro acima e também esse erro de corropção de arquivos?? Eu deduzo que tem haver com a migração dos campos memos de DBT para FPT. Vale lembrar que usei um programinha chamado DBT2FPT.

Atenciosamente,

Josmar

Eu deduzo que tem haver com a migração dos campos memos de DBT para FPT

Eu também acho. Talvez na migração ao executar o DBT2FPT você não deu o mesmo nome que devia dar. De todas as formas, você não quer ver-se livre desse campos do tipo MEMO ? Esses campos, acostumam dar corruption no bd. Eu aconselharia você ler este tópico e ao invés de utilizar campos memos passaria a utilizar arquivinhos txt. Nem todos os registros acostumam ter observações, certo ? Pelo sim ou pelo: eu aconselho mudar.

Leia estes tópicos:
https://pctoledo.org/forum/viewto ... 398#p17337
https://pctoledo.org/forum/viewto ... campo+memo

Ahhh pesquisando e relembrando... ví a minha indicação pra você mudar campo memo para txt, lembra ?
https://pctoledo.org/forum/viewto ... emo#p62462

Você questionou e agora você mesmo tem a resposta... mude, que você não irá se arrepender. Inclusive vai servir muito para o seu aprendizado. Se você tiver dúvidas, poste aqui parte do seu código, com alguns exemplo e estrutura de dbfs que iremos lhe ajudar. Boa sorte colega !

É Pablo, acho que estou sem escolha, to a fim de aceitar esse desafio. Mas te pergunto uma coisa: as informações do campo Memo, é possível migra-las para o TXT ??
Esqueci de comentar outro detalhe do primeiro erro. Quando gera esse erro, os dados são todos apagados..
Josmar

É Pablo, acho que estou sem escolha, to a fim de aceitar esse desafio.

Vai ser bom pra você e seus clientes !

Mas te pergunto uma coisa: as informações do campo Memo, é possível migra-las para o TXT ??

Com certeza. Cómo você faz para ler os campos memos ? A única diferença que para gravá-los você não usará mais o replace, irá usar o memowrit ou fwrite (dependendo o tamanho dos textos).

Esqueci de comentar outro detalhe do primeiro erro. Quando gera esse erro, os dados são todos apagados..

Visto que algo deu errado com a sua migração, aconselho sempre fazer uma cópia e trabalhar encima dessa cópia e depois de ter assegurado o sucesso, aí sim fazer no local do cliente.

Os campos memo são campos textos que são armazenados num arquivo aparte do DBF mas que mantém um vinculo atarvés de uma chave interna e quando alguma dados sofreu alguma inconsistência, aí fica tudo bagunçado. Então você terá que fazer um programa para que leia o seu DBF e o seu campo memo, uma vez lido é só gravar em arquivos. Claro esses arquivo deverão obdecer algum critério de identificação. E o melhor jeito é fazê-lo através da nomenclatura do arquivo (nome do arquivo). Lembre que em Clipper esse nome deve obedecer o padrão 8x3 (nome curto). Possivelmente esse arquivo deve ser um arquivo de clientes (digamos que sim, pois você precisaria dizer pra nós e mostrar a sua estrutura. Para listar a estrutura copiar e colar aqui utilize o meu aplicativo: clique aqui pra baixá-lo) então esse arquivo de clientes ele deve conter um código de cliente (ai fica mais fácil), se esse código for até 7 digitos como máximo você pode compor a nomeclatura do arquivo desta forma por exemplo: "M0000001.txt" esse primeiro caracter a letra "M" (só pra dizer que é um arquivo de Memorandum ou observações) e a nomenclatura deve sempre começar com caracter alpha (nunca numérico). Outro detalhe importante é armazenar esses arquivos numa pasta específica, assim naõ fica tudo misturado na pasta do seu sistema. Então crie uma subpasta dentro da pasta do seu sistema com o nome de "MEMOS". Então na hora de você criar esses arquivos você o fará com o memowrit (se os textos não forem muito enormes), por exemplo:

cArquivo:="\dir_seu_sistema\MEMOS\"+STRZERO(cod_cliente,7,0)+".txt"

E sempre que precisarem ler, alterar, deletar ou até mesmo criar alguma observação, você lê o conteúdo do arquivo (se já existe) e utiliza as função de memoedit e memowrit para gravar. Ok ? Quiser mais ajuda, poste estrutura e o seu código na sua tentativa de migração do campo memo, ok ?

Olá amigos clippeiros !

Não é tão fácil se livrar dos campos memo e dos arquivos .DBT.

Senão vejamos:
- quando nós temos arquivos com códigos fáceis de gerar um .TXT, como no caso de clientes e fornecedores, por exemplo,
geramos os arquivos "Mcl00001.txt" para o cliente 00001, "Mcl00002.txt" para o cliente 00002 e assim por diante;
- o mesmo pode ser feito para os fornecedores, gerando os arquivos "Mfo00001.txt" para o fornecedor 00001 e assim vai...
Pode dar alguns milhares de arquivos, talvez, e a segurança fica total.

Agora, em meus sistemas eu uso os campos memo em arquivos de lançamentos contábeis, por exemplo, para ter um campo
que chamo de histórico detalhado, para poder colocar todo o histórico que não couber no histórico padronizado, permitindo
inserir tudo o que for necessário ao dito cujo.

A estrutura desse arquivo de lançamentos é a seguinte:

Campo Tipo Tamanho Decimais
_______________________________________
Datalcto Data 8 0
Conta Caract 4 0
Documento Caract 10 0
Historico Caract 25 0
Sinal Caract 1 0
Valor Número 12 2
Datareal Data 8 0
Detalhado Memo 10 0 -----------------------> esse é o campo que vai para o .DBT
Operador Caract 5 0

Qual seria a forma de passar o conteúdo desse campo para um arquivo .TXT ?

Como nomear esses arquivos, visto que teríamos de acessar posteriormente esses arquivos nas manutenções dos lançamentos ?

Não podemos nos esquecer que seriam milhares e milhares de arquivos, pois as empresas geram milhares de lançamentos mensalmente em suas contabilidades.

No final de um ano o número seria enorme.

Amiguinhos,

A alguns anos ficavamos calculando os tamanhos de campos por causa das parcas quantidades de memórias das máquinas, criavamos overlays e PLLs em nossos sistemas afim de caberem na memória e ai por diante.

Como os linkers memlhoraram o acesso a mais memória nas máquinas arrisco até a dizer que voce pode extravagar um pouco mais.

Ao invés de criar arquivos .TXT externos e eliminar o uso de MEMOS, analise o tamanho dos conteudos nos arquivos e dependendo da quantidade de dados, salve-os em campos texto de tamanho maior, exemplo, observacao1, observacao2, observacaoN, todos de tamanho 255. Voce teria pelo menos 750 caracteres de texto para salvar.

Veja que já ultrapassamos a fase de usar somente os 640kb que o DOS fornece e portanto, falta de memória não será problemas.

O grande problema dos MEMO é que eles não controlam deleções, ou seja, registro deletado no .DBF não elimina o vinculo no .DBT/.FPT e ai ocorrem os erros.

Aqui no forum tem uma função que faz pack no arquivo MEMO que consiste em uma copia de estrutura e dados da tabela afetada para uma nova e remomeada.

Inclusive uma boa prática é voce criar as estruturas vazias em CDX e puxar os dados NTX antigos e não somente transformar o arquivo de MEMO.

De qualquer forma voce tera de rodar uma rotina e jogar os conteudos de um lugar para outro, seja do MEMO para campos ou .TXTs.

A maior diferença no caso do uso de um arquivo externo é sua maleabilidade. Não precisará ser somente um .TXT. Voce poderá vincular ao registro, um .DOC, um .PDF, etc. ou vários.

Billy escreveu:..//..
Detalhado Memo 10 0 -----------------------> esse é o campo que vai para o .DBT
Operador Caract 5 0

Qual seria a forma de passar o conteúdo desse campo para um arquivo .TXT ?

Como nomear esses arquivos, visto que teríamos de acessar posteriormente esses arquivos nas manutenções dos lançamentos ?

Visto que este arquivo não possui nenhuma referência sequencial como numero do cliente ou numero de cpf, então aconselho:

1. Nesse arquivo crie um novo campo, onde você colocará o nome do arquivo txt.
2. Crie uma nova tabela, com nome por exemplo: MEMOS.DBF com um campo para cada arquivo que não contenha referência sequencial como cod_cliente ou cod_fornecedor como é no caso do arquivo de lançamentos (que você não disse o nome, mas daremos o nome LANCTOS.DBF). Então imaginei esta estrutura:

LANCTOS <N> 7,0
...(se tiver outro dbf sem referência sequencial, adicione mais outros dois campos)...
IMOBILIZADO <N> 7,0

3. Toda vez que precisar abrir um novo arquivo MEMO, você irá consultar no arquivo MEMOS.DBF qual seria o número sequencial da vez e acrescenta +1 para que fique disponível a sequência para um novo arquivo no futuro.
4. Uma vez obtido o numero você irá compor a nomenclatura do novo arquivo TXT (lembre que o primeiro caracter ao menos deverá ser do tipo ALFA). Para maior segurança, faça a verificação IF FILE(nome_do_txt) para saber se já não existe antes de vincular esse nome/numero do txt a esse novo registro. Caso tenha acusado a existência, é porque furou na hora de pegar o novo número de sequência no MEMOS.DBF, daí então pegue outro novamente, até ter certeza que essa sequência não é furada. Normalmente não é para furar, pois a leitura do número sequencial que foi utilizado e a tomada do numero (adicionado +1 aquele numero e gravar no MEMOS.DBF) é coisa super rápida. Mas as vezes o usuário desiste no meio da inclusão e toma o número a toa. Mas se pular não seria o problema, então acho que mais de 9.999.999 TXTs não vai ser, não é ? Caso for,ao invés de ser extensão .TXT utilize esse mais 3 dígitos.
5.Ja sabendo a nomenclatura desse arquivo texto, faça o replace no novo campo do arquivo LANCTOS.DBF, para que quando o usuário desejar incluir, editar ou visualizar o arquivo, o sistema verificará se nesse campo estiver prenchido, daí pega o arquivo que for mencionado. Se esse campo estiver em branco é porque não tem observação ainda.

Eu já tinha aconselhado a armazenar os arquivos extraídos do campo MEMO em pasta exclusiva para isso e dependendo do volume e sub-pastas desdobrando de 100 em 100 arquivos. Tendo a regra definida, não é dificil não implantar, basta utilizar a mesma regra de armazenamento e de conceito para nomenclatura. Agora adiciona-se a questão de arquivo que não possuem código de referência sequencial, então abra um novo campo.

Espero ter ajudado. Pode postar as suas dúvidas que terei prazer de ajudá-lo, ok ?

Concordo com o Rochinha.

Não vejo nenhuma vantagem no uso de campo tipo Memo, eu mesmo nunca fiz uso do tal, nem mesmo quando não tínhamos tanto espaço disponível, minha opinião é que é mais interessante o uso de campos do tipo Caractere.

Uma opção seria o uso desta forma (Exemplo) :

MEMO.DBF

CLIENTE N 6
TEXTO C 254

Inserir nesse BD as informações que você colocaria no MEMO utilizando o campo Cliente como chave de relacionamento. Então esse arquivo só teria dados dos clientes que tivessem alguma informação adicional e facilitando muito o trabalho de manutenção.

Até logo.

Marcelo

Amigo Pablo Cesar,

A sua sugestão é ótima !
Realmente, dá para gerar a chave e colocar em novo(s) campo(s), dentro do próprio registro, para posterior acesso.

Vou implementar a ideia e divulgar o resultado, pois já estou cansado dos problemas dos campos memo que apresentam conteúdo
completamente dispares do que era para ter.