PC Toledo

Amigos, de tempos em tempos me acontece este erro:

hb_cdxIndexPageRead: Read index page failed.

Já deletei os indices e nada. O Kapiaba tentou me ajudar, passando algumas configurações mais mesmo assim de tempos em tempos acontece o erro:

Estou fazendo assim para chamar o RDDCDX, por favor me ajudem:

xharb 1.1 + fwh 8.02 + CDX


PRG:


ANNOUNCE RDDSYS
REQUEST OrdKeyNo, OrdKeyCount, OrdKeyGoto
REQUEST DBFCDX, DBFFPT

FUNCTION MAIN()

RddSetDefault("DBFCDX")

...

amigao faço assim no meu e nunca deu problema !!!



Function Main()
Public _caminho
HB_SETCODEPAGE("PT")

request DBFCDX
RddSetDefault('DBFCDX')

SET INTERACTIVECLOSE OFF
Set date british
Set century on
Set epoch to year(date())+30
Set browsesync on
Set deleted on
Set multiple off warning
Set tooltipballoon on
Set navigation extended
Set SoftSeek OFF
SET CODEPAGE TO PORTUGUESE
SET LANGUAGE TO PORTUGUESE

Olá... tive o mesmo problema, mas é muito raro, então o q fiz um colocar um TRY CATCH

Boa tarde Pessoal, estou tendo as vezes esta mensagem. Mas não sei aonde acontece.
Como vocês sabem qual o dbf que apresenta problema? Tem alguma rotina de teste de indices?

Obrigado, abraços,

Ola!
É xHarbour ?
Use o Harbour 3.2 ou 3.4
Em mensagens acima tem comandos que nem é do Harbour é de alguma LIB gráfica, talvez Minigui e não tem nada a ver com RDD.

Saudações,
Itamar M. Lins Jr.

Ola Itamar, obrigado pela resposta.

Eu uso Xharbour.
O problema é em alguma tabela mesmo, porque refazendo o cdx fica normal.
Vou procurar na web alguma forma de trabalhar esta função , ja achei que ela checa o tamanho do arquivo, mas ainda preciso entender melhor.

Obrigado, abraços,

Aparentemente, o erro ocorre pois a pagina que era para conter a informação que está sendo pesquisada, não existe...
O que pode causar isso é: O index não foi atualizado com as novas informações

Uso muito indice temporario criado com ADDITIVE MEMORY no final, e percebo q depois de muito utilizar se faz necessário recriar o indíce.

vou dar um exemplo

Tenho uma indice chamado Mov (de movimentação) dentro dele tenho
MOV1, MOV2 ... até o 9
e em determinada situação para filtrar crio um indice temporario com o comando no final ADDITIVE MEMORY, q vai criar a ordem 10 no caso
blz tudo certo.
Conforme o usuário vai trabalhando no dia na maioria das vezes não da problema, mas com o passar dos dias (não sei se é q vai acumulando), em determinado momento da esse erro, mas se o cliente sai da rotina em questão e volta ou sai e volta no sistema não tem mais esse tipo de problema.
Não sei o q ocasiona ele. Mas é muito raro de ocorrer.

Ola Pessoal, obrigado pela informações.

No grupo do xharbour o pessoal avisou de uma atualização do xhb build 10259 que contempla agora indicação de qual tabela esta com problema.

abraços,

claudiochaves escreveu:No grupo do xharbour o pessoal avisou de uma atualização do xhb build 10259 que contempla agora indicação de qual tabela esta com problema.

Tô enxergando direito?
Com base na linha do erro, é só olhar no fonte.
Ou não tinha isso?

É por isso que gosto da minha errorsys kkkkkk

Mas vamos ao problema:
O índice está estragado.
Possíveis causas: muitas

Vamos à básica: já está usando CDX ?

Acredito que quase ninguém use NTX e pelo mesmo motivo os desenvolvedores nem percam tempo mexendo em NTX.

Na prática também tenho esse problema, talvez uma vez cada 6 meses, mas nunca reindexo, então considero até normal de vez em quando.
Mas também acontece por falhas de rede.

Ola!
Está usando MT NO xHB ? O tal workaround...Gambiarra no português.do xHb.

Tem um bugs corrigidos no LetoDbf, veja se vc está acessando a tabela com PAGINAS diferentes, PT850, UTF8, PTISO, etc...

Saudações,
Itamar M. Lins Jr.

Só um complemento:

O Harbour utiliza HB_OUT.LOG para erros que não passam pela errorsys.
Na minha errorsys faço uso do mesmo arquivo, portanto, ao usar HB_OUT.LOG pego qualquer erro em geral, inclusive erros "não tratáveis".

Talvez encontre algo nesse arquivo.

Estou tendo o mesmo problema com DBF+CDX usando harbour 3.2 conforme cito neste post https://pctoledo.org/forum/viewto ... 45#p139045 ocorrendo aleatoriamente.

ClaudioChaves, conseguiu alguma solução no seu caso?

Lembrei de uma coisa, que tem programador que ainda faz, que já era ruim no Clipper e no Harbour é pior ainda.

DO WHILE ! Rlock()
ENDDO

Isso mata Windows, rede, CPU, e tudo mais.

DO WHILE ! Rlock()
Inkey(0.3)
ENDDO

Assim é uma maravilha.
Mas se for Clipper.... melhor usar apenas OL_Yield() dentro do DO WHILE.

Vamos recapitular como eu uso, e dificilmente tenho problema:

RecLock()
REPLACE ...
RecUnlock()

Se um usuário altera "simultâneo" ou não, dá no mesmo.
Qual a diferença de alterar 1 segundo depois ou 1 hora depois? o último que altera é o que fica, então não precisa critério diferente, ou deixar registro bloqueado.
A exceção seria pedidos, pra não mexerem enquanto está emitindo nota.
É bloquear, salvar e desbloquear, nada de deixar uma eternidade bloqueado.

O usuário vai almoçar e deixa o sistema aberto... dane-se... não tem nada bloqueado, não tem nenhum problema.
Mas se deixar registro bloqueado..... O cara vai almoçar, e fica tudo bloqueado, gerando problemas.

Fora isso, o default do Windows é uns 15 minutos pra terminal desocupado.
Se o terminal não conversar com o servidor, o servidor fecha a conexão, e vai reabrir quando o terminal voltar a conversar.
Se o cara deixou o aplicativo aberto e foi almoçar... quando voltar o Windows vai ter deixado a rede de fora, e vai dar erro.
Talvez até esse erro de leitura de CDX, porque a rede se desconectou e o Harbour não espera reconectar.

"Aguarde... que o registro está bloqueado por outro usuário"
Essa mensagem nunca mais vai acontecer, porque cada usuário só vai bloquear por uma fração de segundos, só pra fazer REPLACE.