MemoEdit() - .DBF/.FPT ou .TXT ??

[Clash]

Olá amigos,

Desculpem abrir novo tópico por assunto já comentado em outros post´s, mas percebi que alguns são mais antigos, até mesmo atrás de atualizações/melhorias de linkeditores. Então...

MemoEdit()
Não tive problemas com ele em formato .FPT como vejo muitos comentários aqui no fórum, até hoje.
Onde não sei o porque, aconteceu um Corruption. Então pesquisei novamente no fórum alternativas.

Pergunta: Uns sugerem arquivos separados. Ex.: 1 arquivo .DBF com o cadastro de Clientes, outro com o código e campo memo, relacionado ao primeiro .DBF, ou até através de dbSeek(). Outros já sugerem o uso de .TXT com o código do cliente e o memoread/memowrite.

O primeiro caso eu até uso, na tabela de Produtos/Estoque, inclusive muito maior que a de CLIENTES e não tive problemas. Tenho a tabela PRODUTOS e a OBS_PROD relacionada.

O que me sugerem? Agradeço desde já.

Clash.

[JoséQuintas]

Tenho vários casos diferentes.
Alguns, pra texto ilimitado, uso arquivo txt.
Outros, preferi criar um campo caractere grande.
E em outros, criei um arquivo pra textos, com tamanho fixo, mas que pode usar vários registros.

[Clash]

Obrigado, JoséQuintas, por atenção e orientação.

Mas então, pelo que entendi, vc optou por não usar Campo MEMO?!

Abs.

Clash.

[JoséQuintas]

Eu usava campo memo.
Um belo dia comecei a ter internal error nisto:

Código: Selecionar todos

USE JPPEDI
INDEX ON PEDIDO TO JPPEDI1
SET INDEX TO JPPEDI1

Alterei o campo memo de observações pra caractere e tudo voltou ao normal.
Era uma rede Windows 98 com quase 100 terminais, e usava SIXCDX, DBF + FPT.

Faz muito tempo, não lembro o código de erro, só lembro que era internal error.
O campo memo não fazia parte do índice.
Em outros clientes não houve problema, mas a movimentação dos outros era muito pequena.

A partir daí abandonei campos memo.

Também tive problemas em outro cliente, fontes de terceiros, onde só converti pra Harbour.
A gravação do memo era sempre adicionando texto ao conteúdo já existente.
A impressão que tive é que o Harbour se perdeu no tamanho do texto, e corrompeu o conteúdo.

Pra mim, como já não usava campo memo, não me interessou ir fundo nisso.

Com certeza vai ter gente questionando isso, por nunca ter tido problema.

[Clash]

Eh José, eu vou migrar para arquivos .TXT com memoread/memowrite, associando o nome do arquivo à um campo no cadastro do cliente.

Valeu pelo histórico.

Abs.

Clash

[JoséQuintas]

(nota: a pergunta foi removida, mas deixar registrado)

O Memoedit() tem seu próprio controle de mudança de linha.
Se está gravando/lendo em partes, tipo Substr(), vai acabar adicionando mais mudança de linha.
E o MemoEdit() ajusta conforme janela, qualquer diferença de tamanho pode causar mudança em local diferente, que pode não ficar visível na tela.
Mostre o campo caractere a caractere, com o código ASCII, pra ver qual o caractere/conjunto usado pelo MemoEdit(), talvez possa substituir antes de gravar.

Código: Selecionar todos

FOR EACH cLetra IN cTxt
   DO CASE
   CASE cLetra $ "0123456789"
   CASE cLetra $ "abcdefghijklmnopqrstuvwxyz"
  CASE cLetra $ "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
   CASE cLetra $ ",+-:."
   OTHERWISE
      ? cLetra:__EnumIndex, cLetra, Asc( cLetra ), Substr( cTxt, Min( 1, cLetra:EnumIndex - 10 ), 20 )
   ENDCASE
NEXT

Isso vai mostrar o caractere, a posição dele, e 20 letras do texto aonde o caractere está no meio.
Vai acrescentando os caracteres conhecidos, e veja o que sobra.
É no que sobrar que vai ter que trabalhar pra fazer o ajuste.

Se não me engano a função HardCR() retorna uma das mudanças de linha usadas pelo MemoEdit()
Precisa confirmar, porque como não faz parte do meu dia a dia, não conheço os detalhes.
Mas lembro de existir esse inconveniente.