PC Toledo

Kapiaba,

O External só é necessário se DESCEND() não estiver explícito dentro do PRG.

1. Explícito
* nao precisa do External
index on descend(data) tag x to y

2. Não explícito
* precisa do External
a=”index on descend(data) tag xxx to yyy”
&a

No primeiro caso, DESCEND() vai ser linkado normalmente (SEM o External), porque ele está visível para o linkador. No segundo caso, não vai ser linkado porque ele está dentro de um string, cujo conteúdo não é obviamente considerado pelo linkador. Aí, sim, precisa do External, pra forçar a inclusão.

É o mesmo caso do STRZERO(), entre outros. Se ele não estiver visível, tem que usar o External.

amigos uso normalmente um registro indexado com o descend


index on descend(str(total + extra)) tag contas to contas

uso o Harbour 3.2 qual voce usa? Harbour ou XHARBOUR e qual a versão?

Olá Paulo, Eolo e Nascimento,

Tem razão. Acabei me prendendo a talvez o que era algum bug de versões mais antigas, e acabei dando informação desatualizada. Com relação ao Str() na função Descend(), chequei a postar em 2013 neste tópico: Convertendo Sistema do GASPRO para Harbour. Não lembro qual versão era a atual na época, acho que era a 2.1.

Mas acabei de fazer os testes tanto com a versão 3.0 como 3.2 e tudo funciona normal agora.

Amigos,

Voltando ao erro 1449, a solução que apresentei funciona, em parte.
Estrou anexando parte do arquivo Sag_atri.prg onde ele se localiza e parte do Sag_estr.prg onde ficam as estruturas do sistemas gerados no Gaspro.
A sitiação é a seguinte: o arquivo tem cinco índices. Se eu usar apenas os três primeiros, funciona normalmente, porém, se eu acrescentar o quarto ou o quarto e o quinto índice, volta o famigerado 1449.
Os camos, as máscaras, os nomes, etc, estão corretos (pelo menos no meu entender) e, até onde sei, o Gaspro aceita até 8 indices com até 10 conjuntos concatenados.
Assim, meu pedido de ajuda é: onde está esse bendito erro?

Sds,

Paulo Muller

Quais são os dbfs e indices com problema?

Paulo,

Mostra como é criado o indice e como ele é aberto

Paulo,

Uma sugestão, acrescenta no módulo principal (main) a função xhb_ErrorSys(), quando acontecer o erro va ser gerado o arquivo de log: error.log

Você vai ter que incluir xhb.hbc na compilação.

Quando acontecer o erro veja no log esta seção:

--------------------------- Detailed Work Area Items ---------------------------

O trecho do fonte deste errorsys que vai detalhar o erro é:

Olá Paulo,

Primeiro, veja que este arquivo tem 6 indices, e não 5.

Não há nada errado com a estrutura do arquivo, e nem tampouco com a montagem do cabeçalho da matriz sistema[001]. Conferi inclusive a ordem dos campos e estão corretas. O erro 1449 que está ocorrendo não se relaciona a nenhum desses dois casos. Algo está errado quando a função Mov_Ptr() é chamada, em algum momento nela, uma das duas macros está recebendo conteúdo inválido para macro, porisso o erro 1449. Creio que devemos nos ater a ela para entender o que está ocorrendo.

O cabeçalho está correto, mas primeiro peço apenas para corrigir algo que está discrepante entre a estrutura do DBF e a máscara informada em sistema[001] com os campos saldo_ant e valor. Veja que ambos campos têm 12 digitos mais dois decimais, no entanto, a máscara na matriz está sendo informada com 9 digitos e dois decimais. Não tenho certeza se pode ser isso, mas tente concatenar colocando ambas com 12 digitos e dois decimais e faça o teste.

Outrossim, apesar da sugestão do colega Alexandre (asimoes), como você não está recebendo a mensagem de erro, penso que é porque você está usando um ErrorSys.Prg personalizado. Se você estiver, sugiro que faça backup dele, substitua pelo original do GasPro para identificar esse erro.

Isso vai facilitar saber em qual das duas macros na função Mov_Ptr() está ocorrendo o erro.

A sitiação é a seguinte: o arquivo tem cinco índices. Se eu usar apenas os três primeiros, funciona normalmente, porém, se eu acrescentar o quarto ou o quarto e o quinto índice, volta o famigerado 1449

Paulo,
Antes de mais nada, você cita 5 índices, mas no fonte que vc publicou, são 6:

{"nr_lancam+DTOS(data)","DTOS(data)+numero","nr_lancam","DTOS(data)+numero+STR(valor,12,02)",;
"DTOS(data)","codlan"},; // chaves do arquivo
{"Lancamento e data","Data e venda","Lancamento","Data, venda e valor","Data","Cod.Lanc"},;// titulo dos indices para consulta
{"0102","0208","01","020811","02","18"},; // ordem campos chaves
{"MO_CAIXA",drvdbf,drvntx},; // nome do DBF
{"MO_CAIX1","MO_CAIX2","MO_CAIX3","MO_CAIX4","MO_CAIX5","MO_CAIX6"},;// nomes dos NTX

De qualquer forma, se o erro 1449 aparece quando vc inclui o índice 4 (que parece ser o vilão da novela), eu incluiria os campos desse índice um a um, testando cada passo:

1. DTOS(data) // compila e roda

2. DTOS(data)+numero // compila e roda

3. DTOS(data)+numero+STR(valor,12,02) // compila e roda

Com isso, dá pra isolar o campo que está causando o erro.

Aliás, eu trocaria o STR(valor,12,02) por STR(valor,12,2).

Além disso, dê uma checada no TAMANHO desse campo no DBF, confirmar se é mesmo 12/2 (ou seja 9 inteiros, ponto e 2 decimais), e também se´ele é mesmo numérico.

Esse erro & me parece resultado de concatenação: quando você junta os campos, um deles não é do formato dos outros e o erro aparece. Acho.


EM TEMPO: no início e a cada passo do teste, apague fisicamente os arquivos NTX, pra forçar que eles sejam reconstruídos.

Bom dia Jairo, Eolo e Alexandre,

Vou seguir as sugestões e retorno.
Na verdade, são 6 os indices, porém, o sexto é gerado pelo Gaspro, automaticamente (Codlan).
O errorsys que eu uso é o do Gaspro mesmo.
De momento, obrigado a todos!

Sds,
Paulo Muller

Jairo e Eolo,

Os campos sd_ant e valor são numérios, com 9 dígitos e duas decimais (9+2+1(do ponto))=12.
Está correto o tamanho e as máscaras são compatíveis.
Tentei a sugestão do Eolo de linkar cada concatenação por vez. Não vai, nem trocando a ordem. Não deixa se acrescentar o quarto índice.
Fiz uma varredura e limpeza nos 3 arquivos que compõe o módulo Caixa eliminando registros em branco, fiz um pack geral, etc. Também nada.
Assim, creio que o Jairo tem razão. Esse erro 1449 na func mov_ptr tem origem na macro da variável chv_. Assim, logo acima da linha 348 coloquei, para obter o retorno, WAIT(INDEXKEY(0)). Retornou uma cadeia nula, seja, nada.
O intrigante é que a mov_ptr funciona 100% e todos os arquivos e não é lógico que, esporadicamente, aconteça o erro. Acho que solucionando isto, o fato de não aceitar índices também será sanado.
Interessante é que se trocar a edita() por uma consulta extra, a consulta funciona normalmente.
Vou continuar a pesquisa, pois, explicação há que ter.

Sds,
Paulo Muller

Olá Paulo,

prmuller escreveu:Os campos sd_ant e valor são numérios, com 9 dígitos e duas decimais (9+2+1(do ponto))=12

Ok. É que eu tinha em mente que se eu quero 12 digitos inteiros e 2 decimais, ao montar a estrutura no GASPro deveria ser informado 15 no tamanho do campo (12 inteiros + ponto + 2 decimais). Mas esqueçe, o prblema realmente não é esse.

Agora você terá que mudar o foco. Precisa descobrir qual situação exatamente está provocando o erro esporadico, e a razão já ficou clara, em determinado momento você está chamando a função Mov_Ptr() mas ao chamá-la a área não está mais indexada. Assim, retorna vazio (diferente de nulo, ou seja Nil ou Null que também provocaria o erro), e então provoca o erro 1449.

Para que você possa fazer um teste, na função Mov_Ptr() coloque antes da linha: o seguinte: Faça o teste e retorne por favor.

Jairo,

Fiz o teste e resultou como vc previu.
O fato ocorre quando acesso consulta (edita()) ou manutenção (editIO) e, somente em alguns dbfs.
Teoricamente a variável chv_, nesses casos, deveria retornar uma cadeia de caracteres nula já que não foi feita nenhuma filtragem. Agora, quando vc acessa o menu, deveria abrir o dbf indexado por seu índice primário, então, a área estaria indexada.
Curioso é que hoje, pela manhã, acessei remotamente o cliente, fiz vários testes e lá está tudo normal. Como tenho por hábito deixar sempre os fontes no cliente após qualquer alteração, seria fácil retornar ao estado antigo, mas, isso seria desistir de entender esse erro concorda?
Pelo menos, estamos evoluindo, já sabemos a origem do problema.
Valeu, vou continuar a briga.

Sds,
Paulo Muller

Estou anexando a tela da consulta com o erro.

Paulo Muller

Paulo, anexe a tela que mostra o caminho (trace) do erro. Fica melhor.