PC Toledo

Olá Galera.

Estou tendo um problema meio estranho, tenho um banco de dados com duas variaveis onde uma é codigo ( caracter ) e descrição ( memu ), funciona legal no cadastro mas quando peço para reindexar ele deleta todos os registros do banco de dados etou usando NTX, o que poderia ser isso, grato pela atenção

O campo MEMO não tem tamanho fixo. Não deve ser utilizado para criar indices, a menos que vc use pedaço de tamanho específico.
Reveja a especificação dos seus arquivos.
Sujestão: Utilize campo caracter com tamanho específico.

Olá GVC.

O meu indice tem como chave somente o campo codigo que é caracter, será que mesmo assim acontece isso?

Colega Everton,

Eu não uso mais esse tipo de campo. Acho que dá muitos problemas. Aceite minha sugestão, e utilize arquivos textos (gravados em sub-pastas específica). Muito provável que seu DBF tenha um campo numérico tipo código do cliente ou algo assim. Nesse caso poderias criar o arquivo texto com o nome digamos: \PROGRAMA\MEMOS\OBS00001.TXT. Desta forma você disvincula todos os resgitros do seu banco de dados com as observações que poderiam ter (e que nem sempre são para todos os registros). Com isto é mais economico (em espaço digo) e muito mais seguro. Experimente. Ahh, a edição você continua fazendo pelo MEMOEDIT()/MEMOWRIT().

Um clip-abraço
:)Pos

Poste aqui a sua rotina de indexação, por favor.

Os registros são deletados (marcados como apagados) ou não aparecem quando o arquivo DBF é aberto com o NTX (aparecem normalmente quando abertos sem o NTX)?

Pablo, agradeço pela idéia de criar arqs ou invés de usar MEMOS. Estava justamente procurando uma forma de livrar dos MEMOS que só dão problemas. Tenho trabalhado muito no meu novo sistema com arquivos de baixo nível. São rápidos e seguros. Valeu a idéia.

Uma pergunta: Que editor vc usa ? Dá pra usar um WORD ou WORDPAD ?
Ou é melhor um editorzinho DOS para não ocasionar problemas de memória como os campos MEMO ? Uso o DBFCDX em rede com um servidor LINUX COM 512 Mb. Os meus dbfs ocupam em torno de 100 Mb. Nas estações, variam em torno de 128 Mb.

Eliane escreveu:Uma pergunta: Que editor vc usa ? Dá pra usar um WORD ou WORDPAD ?

Que bom te agradou a idéia de criar arquivos em lugar dos campos MEMOS.

Só não entendí bem a sua pergunta. Se você que saber qual o editor que eu utilizo para edição (em programação ou manutenção sistemas) utilizo o QE3.EXE (não dá conflito nenhum) e é muito bom.

Agora se quer saber para edição dos arquivos que estão substituindo os de campo MEMO, te diria para usar o MEMOEDIT. Mas se você vê que não dá por falta de memória, aqui tem uma boa solução que o nosso colego "DIGITOM" postou:

viewtopic.php?t=3954&highlight=editor+texto

Legal a gente receber agradecimentos também.
Um clip-abraço

Olá Pablo.

Valeu tbm pela dica meu, eu não mexo com memo, mas já estava me dando dor de cabeça, da forma que vc me falou achei mais confiável e seguro, pois os dados que vão ser armazenados é de muita importancia, valeu pela dica, e obrigado aos outros amigos tbm.

Como eu podria imprimr um campo memo, quando utilizo o indice CDX, e o nome do arquivo memo é do tipo FPT

Pablo César escreveu:

Eliane escreveu:Uma pergunta: Que editor vc usa ? Dá pra usar um WORD ou WORDPAD ?

Que bom te agradou a idéia de criar arquivos em lugar dos campos MEMOS.

Só não entendí bem a sua pergunta. Se você que saber qual o editor que eu utilizo para edição (em programação ou manutenção sistemas) utilizo o QE3.EXE (não dá conflito nenhum) e é muito bom.

Agora se quer saber para edição dos arquivos que estão substituindo os de campo MEMO, te diria para usar o MEMOEDIT. Mas se você vê que não dá por falta de memória, aqui tem uma boa solução que o nosso colego "DIGITOM" postou:

viewtopic.php?t=3954&highlight=editor+texto

Legal a gente receber agradecimentos também.
Um clip-abraço

Como eu podria imprimr um campo memo, quando utilizo o indice CDX, e o nome do arquivo memo é do tipo FPT

Caro jairfab, Bem vindo ao FORUM !.

Bem, eu nunca trabalhei com CDX nem FPT (outra que eu acho que arquivos de índices, não teriam nada a ver com impressão e sim com a sua localização do registro requerido). Mas creio que você tem no teu BD um campo MEMO, no qual você poderá imprimí-lo colocando o resultado desse campo memo em variável. Logo você terá que ler linha a linha dessa variável, por se tratar de texto livre. Você terá que ler linha a linha, considerando o espaço que você tem para imprimir.

Utiliza-se o MEMOLINE() que retornará como SUBTRINGs e com isso mandar para impressora (com os devidos comandos de formatação: condensado, normal, etc..) ou mandá-los para outro arquivo-de-impressão, que a sua vez este poderá ser enviado a fila de impressão.

Um clip-abraço :)Pos

Obs.: Jair, você leu todo o conteúdo, na qual eu desestimulo o uso de campos MEMOS.... (é apenas a minha opinião). E desculpa por eu não responder a tua primeira mensagem sobre Visual LIB 2.0, é porque não trabalho com ela, nem mesmo a tenho.

Olá
Amigos
Boa Tarde


Gostaria de um exemplo de como trabalhar com campos memo, tipo, adicionar, modificar,remover, eu ainda
não tinha trabalhado com esse tipo de variaves, agora preciso.

Gostaria se possivel uma pequena rotina para q eu possa implementar e colocar no meu sistema.

Atenciosamente

Ricardo Sales

Olá Ricardo, o seu novo tópico foi juntado com um já existente. Respondendo as suas dúvidas:

Ricardo Sales Ribeiro escreveu:como trabalhar com campos memo, tipo, adicionar, modificar,remover, eu ainda
não tinha trabalhado com esse tipo de variaves

A edição de campos Memo é simples. Basta carregar o conteúdo (quando é novo registo o conteúdo é vazio) armazenando em uma variável a qual você poderá editar mediante as funções MemoEdit e fazer o replace após edição para aquele campo. O MemoEdit, poderá ter uma função de controle. Nessa função você pode obter o numero da linha e coluna, pode obter a tecla pressionada e tratar de acordo as suas necessidades, também poderá interceptar as saída quando usuário pressiona Ctrl-End pra sair por exemplo. Enfim não há mistérios, o único que tenho a acrescentar que geralmente este tipo de campo, dá problemas. Dá corruption in Memo File. Pois ao criar um campo Memo é criado um arquivo que fica atrelado ao dbf. É nesse arquivo que é guardado o texto, as observações de determinado registro. Eu desaconselho a utilização do campo Memo, tanto pela corrupção que pode vir a ocorrer, quanto a praticidade e segurança que arquivo individuais possam a vir fazer parte do seu banco de dados. Para isto você irá precisar obter um código para relacionar um registro a determinado arquivo texto. A manutenção de arquivos texto se dá da mesma forma que no caso de campo memo como expliquei acima. A diferença é que na hora de gravar, você não precisará mais utilizar replace, em lugar disso você vai precisar gravar mediante o MemoWrit() e para atribuir a uma variavel, MemoRead().

Tem vários tópicos aqui no fórum falando disto: https://pctoledo.org/forum/viewto ... mos#p72248

Um exemplo do que estou propondo você encontra em: https://pctoledo.org/forum/viewto ... emo#p26231 e aqui outro mais completo:
https://pctoledo.org/forum/viewto ... 790#p33790

Bom espero ter esclarecido este tema, que considero importante, mais ainda nesta sua fase de implantação.

Olá Pablo, boa tarde.

Tenho 1 sistema médico que fiz para 2 medicos à +- vinte anos.
Sistema em clipper. Hoje já estou passando para Harbou/Minigui ext.

nesses 20 anos, posso dizer que tive problemas sómente uma vez , e em um medico a poucos meses, então uma parte de uma consulta se perdeu, mas já tive problemas em outros sistemas, numa parada de energia práticamente é fatal. Você tem que fazer um sistema à parte, juntar os pedaços e gravar novamente. Enfim dá muito trabalho.

minha opinião sobre campos memos.
muito prático p/ se trabalhar
facil de manusear
guardo muitas informações num único arquivo
mas tem esse problema de corrupção.

alguns anos atrás, alterei em um outro sistema da seguinte forma ( que como soluçao), não me lembro onde vi, em que criei um dbf. e que cada linha do texto, seria um registro. deu certo mas não gostei. Descartado.

criar aquivos textos seria uma boa saida
Baseado no sistema médico, onde utilizo campos memo para:
-historico
-protocolo
-remedios (para bulas e explicaçoes) por exemplo
historico controlado por consulta
os 2 medicos que utilizam meu sistema fazem em media 40 consultas dia cada
imagina isso 20 anos.
o aquivo fpt estava imenso, nessa atulização para harbour, já separei em arquivos de acordo com a letra inicial do nome do paciente. Então de um arquivo virou 26 arquivos bem menores, que daqui 10 anos não vão estar nem perto do do tamanho do arquivo único que estava.

a ideia do arquivo texto é boa, mas vamos na prática.

apesar de vintes anos de programação, antes de perder um tempo fazendo isso, gostaria de alguma idéia de alguem com mais expreiência, entao PERGUNTO:


vamos tomar como exemplo os textos do historico do paciente
1) p/ cada codigo de paciente um arquivo texto.
sem problemas
2) dentro de cada arquivo texto, 200 consultas desse paciente
ainda não vi um jeito de acessar esse arquivo texto por data de consulta
3) 3000 pacientes
3000 arquivos textos????
isso só de historico, e os outros?.

gostaria de uma opinião:


Poka

Poka escreveu:alguns anos atrás, alterei em um outro sistema da seguinte forma ( que como soluçao), não me lembro onde vi, em que criei um dbf. e que cada linha do texto, seria um registro. deu certo mas não gostei. Descartado.

Já vi e também não gostei, arquivo texto é sempre menor. Apesar do que tenho a te indicar está baseado num dbf de histórico de índice.

criar aquivos textos seria uma boa saida
Baseado no sistema médico, onde utilizo campos memo para:
-historico
-protocolo
-remedios (para bulas e explicaçoes) por exemplo

Para esses casos: Históricos, Protocolo e Remédios você faria com numenclaturas diferentes para diferenciá-los. Exemplo: His00001.txt, Pro00001.txt e Rem00001.txt. Você fez isso ? Pois seriam 3 campos memos.

nessa atualização para harbour, já separei em arquivos de acordo com a letra inicial do nome do paciente

Bom, eu jamais faria com a letra inicial do nome do paciente. E sim a primeira letra do tipo a que se refere o arquivo texto. Digo uma letra, pois assim ficaria 9.999.999 para cada item. Pois bem, você tem no banco de dados N pacientes. Então, essa numeração pode ficar pequena considerando o tempo transcorrido para ser englobado em um único arquivo. Então uma solução seria você armazená-los em sub-pastas de acordo cada cliente. Isto é, cada cliente uma pasta. Inclusive os dados (não cadastrais), senão o de histórico do paciente, poderá armazená-los separadamente e abri-los conforme o código do paciente. Este código (numérico) te ajudará a compor a nomenclatura das sub-pastas.
Exemplo: paciente numero 1, tem uma sub-pasta P0000001 e dentro os arquivos em sequência para aquele paciente. Você pode elaborar um arquivo dbf contendo as datas e os nomes de cada arquivo txt que foi emitido para aquele paciente e assim poder obter o nome do arquivo texto pela data e tipo (historico,protocolo,remedios). Num Grid iria ficar chóia !

Acho que essa idéia resolveria. Só não sei se precisará mais pastas do que 9.999.999. Mas pelo que entendo de Harbour, você não precisa limitar a 8 digitos o tamanho das pastas. Ora porque em Harbour pode abrir/criar arquivos com o path de nomes longos.

Espero ter te ajudado, Poka !

Olá!

Já que você está migrando seu aplicativo para Harbour + Minigui Extended, como informou, sugiro que você migre a base de dados também. Esqueça os DBF/FPT.

Existem ótimas opções de gerenciadores de bancos de dados que são grátis. Entre eles, Postgre, MySQL, SQL Server Express e Oracle XE.