Reindexação de DBFs - quando fazer

[JoséQuintas]

Só a título de curiosidade.
De vez em quando postam sobre reindexar arquivos várias vezes.
Aqui meu log de reindexação, pra uma rede com quase 20 terminais de uso constante, principalmente pedidos, que envolve NF, estoque, financeiro, etc.

Estranhei que teve várias vezes em agosto do ano passado, talvez por trocar Harbour 3.2 e 3.4 só pra garantia.
No geral, era na atualização de versão, queda de energia, ou simplesmente por reindexar.

Hoje é um dos dias que cismei de reindexar, olhei esse log, e lembrei de postagens no fórum.
Então hoje foi a terceira reindexação deste ano, mas não por precisar.

O que usei nos últimos anos:
- SIXCDX em Clipper
- Depois SIXCDX em Harbour
- Por último DBFCDX em Harbour

Atualmente Harbour 3.4 MSVC2010 e módulos usando multithread.
Somente a partir deste ano via terminal service.
E vai ter acesso via hbnetio a qualquer momento.

NUNCA usei COMMIT, só SKIP 0
É assim desde os tempos do Clipper 5.2e.

Qualquer comportamento diferente, melhor revisar equipamento e software.

Nota: Neste ano, finalmente o servidor ganhou um nobreak.

[Abel]

Ola,

quando vc usa skip 0 ?

grato, Abel

[JoséQuintas]

No manual do Clipper, recomendava SKIP 0 pra deixar o registro visível para outros terminais, antes de desbloquear.
Se os outros terminais enxergam, deve ser porque foi salvo no servidor.
Numa versão simplificada das funções:

Código: Selecionar todos

RecLock()
REPLACE ...
RecUnlock()

FUNCTION RecLock()
   DO WHILE .NOT. rLock()
      Inkey( 0.5 )
   ENDDO
   RETURN rLock()

FUNCTION RecUnlock()
   SKIP 0
   UNLOCK
   RETURN NIL

Também o tempo entre teste de rLock().
Parece que não, mas rLock() precisa de comunicação entre terminal e servidor, então melhor uma pausa, senão poderia ser milhares de consultas por segundo.

Aliás, no Clipper entra também aquilo de 100% de CPU, também usava OSLIB durante esse teste.

[JoséQuintas]

Pra constar:

In a network environment, any record movement command, including SKIP, makes changes to the current work area visible to other applications if the current file is shared and the changes were made during an RLOCK().
To force an update to become visible without changing the current record position, use SKIP 0.
If, however, the changes were made during an FLOCK(), visibility is not guaranteed until the lock is released, a COMMIT is performed, or the file is closed.

Em um ambiente de rede, qualquer comando de movimentação de registro, incluindo SKIP, torna as alterações na área atual visível a outros aplicativos se o arquivo atual é compartilhado e as alterações são feitas durante um RLOCK().
Para forçar que a atualização fique visível sem alterar a posição de registro atual, use SKIP 0.
Se, entretanto, as alterações foram feitas durante um FLOCK(), a visibilidade não é garantida até que o LOCK seja liberado, seja feito um COMMIT, ou o arquivo seja fechado.

Como o mais comum é não sair do registro atual após o REPLACE, então nada melhor que um SKIP 0.
A primeira linha menciona "comando de movimentação de registro", não sei se o COMMIT se encaixa nisso.