Problemas em sistema gerado pelo gaspro e convertido

[prmuller]

Amigos,

Estou tendo dois problemas num sistema gerado pelo gaspro (4.o) e convertido com o gas4harbour:
1 - Alguns arquivos não aceitam que se reconstrua índices e, na tentativa, o sistema cai. O mesmo acontece no caso
de de acesso direto pelo menu.
Consigo acessar os arquivos normalmente pelo dbu ou dbnsx. Não creio que seja corrupção de arquivo.

2 - De onde aparece, às vêzes, o famigerado erro 1449 - variável função &, sempre na linha 348 (função mov_ptr) do
arquivo XXX_FUNC.PRG? É certo que é um erro de sintaxe, mas, do nada?

Alguém já passou por isso, ou pode me dar uma luz?
Antecipadamente grato,

Paulo Muller

[prmuller]

Em adendo ao post, que que concerne ao problema 1 relatado, o mais interessante é que mesmo detonando o dbf e os cdx, quando, teoricamente o sistema deveria recriá-los (func criadbf), o dbf é recriado vazio, mas, da pau do mesmo jeito na criação dos indices.

Paulo Muller

[Toledo]

da pau do mesmo jeito na criação dos indices.

Amigo, é apresentado alguma mensagem de erro?
Qual a versão do Harbour você está usando?

Abraços,

[prmuller]

Bom dia Toledo,

Como sempre, prestativo. Obrigado por responder.
Fiz a migração seguindo, rigorosamente as suas instruções, à época, gas4harbour, hmg e harbour 3.2 (mudei para o 3.4) e funcionou extremamente bem.
Esse problema dos índices está ocorrendo apenas em 3 dbfs de mais de 150 no total e, não tem mensagem, simplesmente o sistema cai, seja via reconstrução de índices ou acesso direto.
Quanto ao erro 1449, já me ocorreu algumas vêzes, e, resolvi apagando os *.sys e pw*.*, e, às vêzes substituindo a consulta padrao (edita) por uma consulta extra. Nesse caso, só queria entender o porquê isso ocorre sempre na função mov_ptr e somente em alguns arquivos.
Creio que esta relacionado ao Indexkey(0) da linha relatada no post.
No caso dos indices, como relatei, mesmo recriando do zero, acontece e sempre nos mesmos três dbf.
Estranho não é, pois se trata de um sistema kilométrico e que já roda há mais de 15 anos sem problema algum.
Obrigado pela ajuda e tenha um bom dia!

Paulo Muller

[Jairo Maia]

Olá Paulo,

O Clipper é tolerante com algumas situações que o Harbour não tolera, a rigor, o Clipper trata em algumas situações o que o Harbaour considera erro. Pessolamente não acho que é retrocesso, ao contrário, é mais exigente. Por exemplo: Se em Clipper você usar o comando SEEK numa área não indexada, não ocorre erro em tempo de execução, já em Harbour ocorre o erro: Área não indexada. Isto é um exemplo.

O erro 1449 indica que você está usando string incorreta numa macro.

Quando você usa IndexKey( 0 ), retorna a chave do indice corrente, verifique qual é o retorno da variável: chv_, que recebe a chave do indice atual.

Verifique também como nesse caso está chegando a variável: c_r que é um parâmetro da função Mov_Ptr() e usada numa macro acima da linha do IndexKey( 0 ).

Quanto ao erro na criação dos indices, você precisa verificar se não há alguma chave de indice iválida para o Harbour. Cheque as chaves de indexação dos indices que estão dando erro, e verifique. Caso preferir, poste como você está montando cada chave de cada indice destes arquivos, acho que fica melhor para dar alguma opinião.

[asimoes]

Outra coisa que você deve verificar é se o nome dos campos no index são exatamente os campos do dbf, o harbour exige que seja exatamente igual, diferente do clipper que podia até pegar um nome maior ex.

No campo tem:

cData_Hora

e no index: INDEX ON cDATA_HORAS - o S excedente não era considerado, para o harbour é um erro, campo ou variável não existe.

Veja a estrutura dos dbf´s e veja a composição do index

[prmuller]

Jairo, boa tarde!

Obrigado pelas colocações. Na verdade, eu já parei de programar há alguns anos, e, tenho hoje apenas quatro sistemas rodando em clientes antigos que não querem trocar por outro. Fiz a migração a pedido deles e foi bem tranquilo já que se preocupam mais com as funcionalidades do que com a estética.
O problema dos índices está resolvido. Não sei se era o caso, havia um erro no campo cpf do cadastro de fornecedores com tamanho maior e máscara incompatível. Fiz as alterações, executei o adaptador e fluiu normalmente acertando, de quebra, os dois outros.
O erro 1449 no cadastro de fornecedores desapareceu e as consultas, inclusive as gravadas, estão legais, mas, nos dois outros, permanecem, porém por se tratar de dois arquivos pequenos e auxiliares que não são usados mais não preocupa.
Quanto à variável chv_, não dá para pegar seu retorno pois é justamente nele que ocorre o erro.
A variável c_r retorna um erro base 1003 (variável inexistente) e, a variavel chv_1 não retorna nada.
Vou tentar aprofundar as pesquisas para tentar descobrir o porquê acontece isso (aí no fórum está cheio de reportes semelhantes, porém sem uma solução definitiva).
Se partirmos do princípio que a função mov_ptr é montado pelo gaspro e que funciona em todas as consultas não tem muita lógica falhar em uma. No caso dos dois arquivos, com certeza não são os índices. Ambos são primários, apenas o código, caracter com seis dígitos e máscara compativel (999999), mas, que está relacionado à indexkey() é quase certo.
Interessante é que se vc trocar a opcão consulta (funcao edita()) por uma consulta extra, volta tudo ao normal, menos a manutenção.
Eu me recordo de que, há muito tempo atrás, consegui resolver fazendo uma correção da linha da função e cheguei a postar no fórum do gaspro, mas, não consegui localizar.
De qualquer forma, valeu mesmo pela força e, se eu tiver algum progresso nisso, posto, pois pode ser que ajude a outros (esse erro é realmente irritante).
Deus te abençoe!

Paulo Muller

[prmuller]

Jairo e Toledo,

Ambos os problemas foram totalmente sanados e, estavam interligados.
No caso do arquivo de fornecedores, o ínidice 4 (cpf) estava com campo maior e sem máscara.
No caso do arquivo de contas correntes, os índices 1 e 3 eram redundantes, o mesmo acontecendo no arquivo de pedidos. Foi somente efetuar as correções e tudo voltou ao normal.
A dedução é de que esse erro 1449, quando provocado pela mov_ptr está relacionado à indexkey() e, em última análise, aos índices do arquivo.
O inconveniente, que não é nenhum problema, é que as consultas gravadas tem que ser apagadas e refeitas para voltarem a funcionar normalmente.
Estou postando para que outros, se tiverem o mesmo problema, saibam a origem do fato.
Finalizando, obrigado a ambos por me responderem.

Paulo Muller

[prmuller]

Jairo,

Uma última pergunta: existe algum tipo de restrição quanto ao uso de índices como STR para campos numéricos e DTOS para campos data no Harbour?

Paulo Muller

[prmuller]

Complementando, não postei o índice: DTOS(data)+numero+STR(valor,12,02) é compatível com o Harbour?

Obrigado
Paulo Muller

[Jairo Maia]

Olá Paulo,

existe algum tipo de restrição quanto ao uso de índices com o STR para campos numéricos

Apenas se voce for usar a função Descend():

Código: Selecionar todos

Descend( Str( nCampo ) ) // isso não funciona
Descend( nCampo ) // sem o Str() funciona

e DTOS para campos data

Não! Nenhum problema.

DTOS(data)+numero+STR(valor,12,02)

Considerando que o campo numero é tipo caractere (e pela lógica dessa chave deve ser), não há nada incompatível com Harbour nessa Chave de Indexação.

[Eolo]

Descend( Str( nCampo ) ) // isso não funciona
="719">Descend( nCampo ) // sem o Str() funciona

Jairo,

Alguma coisa mudou do xHarbour pro Harbour? O STRZERO funciona, mas o STR não?

Eu uso (não o STR, mas) o STRZERO com DESCEND, em muitos casos, e funciona normal. Alguns exemplos:

index on strzero(nbarr,14,0) + descend(dtos(pdata)) + descend(strzero(pcodi,10,0))
- código de barras (N) + data decrescente da compra (D) + ordem descrecente do item da compra (N)

index on strzero(xseto,3,0) + descend(strzero(xtotv,9,2))
- setor (N) + total decrescente da venda (N)

index on descend(dtos(natua)) + acento(onome) + descend(nhora) + acento(nnome) + strzero(nbarr,14,0)
- data de atualização decrescente (D) + setor (C) + hora decrescente (C) + cliente (C) + código de barras (N)

[Jairo Maia]

Eolo, não sei dizer em relação ao xHarbour para Harbour, trabalhei pouco com o xHarbour. Mas em Harbour, se usar Descend() num campo número não pode usar o Str(), se não a ordem descendente fica sem efeito.

Quanto a usar StrZero(), confesso que não sei porque nunca usei. Mas se da forma que você colocou funciona fica como uma dica.

[Kapiaba]

Bom dia, em xHarbour basta dizer ao compilador:

Código: Selecionar todos

   EXTERNAL DESCEND

Abs,

[Jairo Maia]

Olá Kapiaba,

Acho que você se enganou. Na verdade, no seu exemplo o comando EXTERNAL informa ao compilador para compilar a função Descend(). Normalmente se usa esta função para chave de indexação, então elas estarão entre aspas (strings) e se não fizer a chamda para o compilador incluí-la, ao tentar gerar o indice teremos o erro: Função não existe: Descend().

Tem o mesmo efeito usar:

Código: Selecionar todos

EXTERNAL DESCEND ou REQUESTE DESCEND