Bug no Xharbour 1.0.0: acesso via DBFCDX

[lugab]

Olá, pessoal.

Acabei de confirmar um bug no xharbour 1.0.0 , no momento de dar um Seek simples num DBFCDX, em um programa muito antigo, convertido/compilado em xharbour 1.0.0.

O

Código: Selecionar todos

Seek Str(codigo,3)
If eof() 

só funciona se DBFCDX possuir poucos registros e se o tamanho do programa executável for pequeno.

Compilei o programa sozinho (executável pequeno) e ai o seek funcionou em vários pcs, mas qdo o programa faz parte do sistema e o executável cresce, o SEEK se perde e acusa que o registro não foi achada , via eof()

Antes o executável funcionava redondo, mas , bastou atingir , tipo 5000 registros (o que é menos de um ano de digitação) e agora o seek simplestmenta diz que nada acha, mas o registro sempre esteve la.

O correto seria eu mudar para uma xharbour superior, mas eu estou preso a esta versão, pq adaptei meu sistema para funcionar com uma lib privada, chamada XVL.LIB (velha visual lib recompilada ), que só foi compilada para o xharbour 1.0.0.

O que vcs fariam para fazer funcionar o Seek em qualquer situação, considerando q não podem sair do Xharbour 1.000, face essa trava de ter que usar a lib privada, além de :

- diminuir o tamanho do executável, ou
- dividir o sistema em 2/3 módulos ?


Poder-se-ia, p.ex, usar uma RDD ( dbfcdx ) não natiuva, que funciona no xharbour 1.00 ?

Se sim, qual RDD ?

Grato,

gabriel

[Itamar M. Lins Jr.]

Pode postar um screenshot mostrando as telas dessa lib ?
Porque não é possível compilar essa lib usando o xHarbour atual ?

Saudações,
Itamar M. Lins Jr.

[lugab]

Itamar, trata-se de uma lib comercial e a gente só compra ela já compilada. Já fi\z contato com o fabricante dela, e já sei q ela não foi e nem será atualizada para xharbour superior.

Aqui, neste link http://www.vagucs.com.br/cgi-bin/vagucs ... dioma=ptbr vc pode ter uma noção exata do que se trata esta lib..

Obrigado pela atenção

[alaminojunior]

Gabriel, sem querer duvidar da sua experiência, mas eu já utilizei esta versão do xHarbour por muito tempo, e também temos colegas que ainda usam e sinceramente nunca tive este tipo de problema.

Antes o executável funcionava redondo, mas , bastou atingir , tipo 5000 registros (o que é menos de um ano de digitação) e agora o seek simplestmenta diz que nada acha, mas o registro sempre esteve la.

Isso cheira a índice desatualizado. Talvez já saiba, mas CDX deve sempre ser deletado antes de ser criado novamente. Coisa que não acontece com NTX.

Enfim, tenho um colega em específico, que utliza programas xHarbour para missões digamos...críticas há alguns anos e até agora foram só elogios.

[angeiras]

Olá Gabriel,

Também uso a versão 1.0.0 do xHarbour e até agora não me deparei com nenhum bug em relação ao DBFCDX. Já uso o xHarbour em 4 sistemas convertidos e um deles, de varejo, tem DBFs com mais de 500.000 registros funcionando redondinho.

Tem como voce criar um programa de exemplo pra gente ver o erro ?

[]s
M.Angeiras

[lugab]

Alamino e Angeiras, eu confesso que fiquei feliz com a defesa da versão a vcs fizeram.

Feliz, pq é melhor q seja um erro meu, do que um bug da rdd...

Mas eu fiz tudo certinho, pq é muito fácil. Eu deleto todos os .CDX antes de reindexar.

Vejam um pequeno resumo do meu código de indexação:

Código: Selecionar todos

procedure main

SET ESCAPE  OFF
SET WRAP ON
SET TALK OFF
SET DELI OFF
SET BELL OFF
SET DATE BRITI
SET DELE ON
SET EXCL OFF
SET FIXE OFF
SET EXAC OFF
SET CENT OFF
SET EPOCH TO 1960

Request dbfcdx
Rddsetdefault("dbfcdx")
Dbsetdriver("dbfcdx")

Run del *.cdx /s /q  > nul  // deletando indices

*-----  abrindo e indexando um arquivo qualquer -----*

SELE 20
USE EMPR EXCLUSIVE
IF NETERR()
   Alert('EMPR sendo usado....Tecle Algo P/Encerrar')
   QUIT
ENDIF

INDEX ON STR(NUMEMP,2) TAG EMPR0 TO EMPR
INDEX ON NOMFAN TAG EMPR1 TO EMPR

[alaminojunior]

Gabriel, até aí está correto. Por enquanto, gostaría de ver a sua rotina de indexação e a de abertura de arquivos para trabalho.
Eu acrescentaría à sua rotina inicial o comando

Código: Selecionar todos

SET AUTOPEN ON

, uma vez que usa nomes iguais para dbf e cdx. Com isso, você estaría prevenido contra uma possível falha (humana ou não) na abertura dos índices juntamente com as tabelas.

[alberto_dias]

Prezado AlaminoJunior,
A muitos anos deixamos de usar o indices .ntx e passamos a usar o .cdx
passamos a usar o DBFCDX, em todos os nossos Sistemas.
Foi muito bom, melhorou muito, ficou mais estável, mas em algumas vezes,
( poucas vezes) em alguns clientes, inexplicavelmente, o sistema perde a
ordem dos indices, na hora de salvar um pedido, uma nota fiscal, ele sobrescreve
a um número que já existia, lança em um número antigo, nunca conseguimos
descobrir o que acontece, a gente as vezes fica com a cabeça
quente e não consegue chegar a lugar algum.
======================================
seria porque eu nunca usei este SET AUTOPEN ON ?
li esta sua mensagem e fui até ao xHarbour Reference e o manual indica também
utilizar o SET AUTORDER TO 1, junto com o SET AUTOPEN ON
Na sua opinião,
Se eu utilizar estes SET'S poderiam ocorrer menos falhas no Sistema ??
Estas falhas, são só Humanas de programação ou podem ser de máquina também ??
Agradeço desde já se vc poder ajudar nestas dúvidas,

[alaminojunior]

mas em algumas vezes,
( poucas vezes) em alguns clientes, inexplicavelmente, o sistema perde a
ordem dos indices, na hora de salvar um pedido, uma nota fiscal, ele sobrescreve
a um número que já existia, lança em um número antigo

Bom dia.
Sobre perder a ordem dos índices (que no caso de CDX, vamos aqui chamar de "ordem"), eu procuro (procuro) sempre manter um bom controle sobre qual ordem estou usando no momento.
O comando

Código: Selecionar todos

SET AUTOPEN ON

faz com que o arquivo de índice seja aberto assim que o DBF for aberto, desde que os dois tenham o mesmo nome de arquivo.
Se você usa os mesmos nomes de arquivos para os DBF´s e CDX´s, sería interessante usar este comando, pois você fica despreocupado.
Ou se usa nomes diferentes como eu, sempre tenha certeza de que emitiu um

Código: Selecionar todos

SET INDEX TO índice

após a abertura dos DBF´s.
Feito isso, basta se concentrar nas ordens utilizadas em cada rotina.
Outra coisa é sempre testar os comandos/funções emitidos. O comando

Código: Selecionar todos

USE ... 

por exemplo (assim como outros), precisa ser testado para termos a certeza de que foi executado com sucesso.

• Moral da história é que as vezes pecamos por excesso de confiança e isso é fatal em programação. Confiamos de olhos fechados que determinada rotina vai fazer algo, e de repente alguns meses depois o cliente liga reclamando. Por isso é imprescindível testar muito a sua aplicação, analisando sempre o pior caso possível (e eles existem, o Murphi que o diga). Gostaría de comentar também o seguinte: a nossa experiência de programação vai aumentando conforme o tempo, e com isso passamos a exigir/explorar sempre mais da ferramenta que utilizamos, sem as vezes contudo, ter idéia de que ela vai exigir em troca um aumento de cuidados de nossa parte.

Estas falhas, são só Humanas de programação ou podem ser de máquina também ??

Não estão descartadas não, mas pelo relatado parece mais algum deslize no código. Esfrie a cabeça, e faça uma análise bem detalhada das rotinas.