INDEXAÇÃO CONSTANTE

[aferra]

tudo foi feito para HARBOUR, desculpe não ter informado.

Para a função WIN_OSNETREGOK() esses dois links, para entendimento e funcionalidade para xHarbour

http://www.pctoledo.com.br/forum/viewtopic.php?f=4&t=11325&p=89476&hilit=WIN_OSNETREGOK#p89476

http://fivewin.com.br/index.php?/topic/21857-function-dbinfo/?hl=win_osnetregok#entry264320

o restante é igual para os dois.

[oribeiro]

Vagner,

Qual é o segredo de deixar uma aplicação rodando tanto tempo sem a necessidade de se recriar os índices?

Além da dica de colocar o DbSetOrder(0) antes do DbAppend() há outros macetes?

Aguardo, obrigado.

[vagner]

Nada de anormal Oscar, somente tomar muito cuidado, com os append da vida, travar corretamente e destravar, ter uma rede estável, para vc ver tenho um cliente, que está fazendo este ano de 2014, 6 anos de trabalho, e sem reorganização, é uma maravilha, o cliente, nem têm aqueles botões que eu costumava antigamente colocar "reorganização" , veja que o DbSetOrder(0), eu comecei a usar depois de uma discussão sobre o assunto onde o Eduardo Motta e o Villiam, me falaram, antigamente eu usava o seguinte recurso :

Se eu tinha que dar um "replace" no campo do nome eu mudava o índice para o um que não tinha o nome como chave, isso funcionava, porém eu tinha que sempre ficar mudando e saber se tal índice tinha ou não o field, com o DbSetOrder(0), não preciso me preocupar com isso além de estar voltado para "0" ele atualiza os outros índices sem problemas

vou dar um pequeno exemplo :

DbAppend() -> Não necessita travar o registro depois, pois ele mesmo já trava, nem precisa mudar o índice, pois não há nada nele para poder corromper

Já o RLock(), esse sim precisa ser tomado cuidado, pelo que eu reparei na época que me corrompia os índices, era justamente o motivo de eu tentar alterar o field onde ele se encontrava no índice

Sempre que usar um desses dois, use o dbcommit() e dbunlock(), em seguida, muitos esquecem do dbcommit(), e dão direto o dbunlock(), onde destrava o registro sem antes "commitar" os dados

[JUDSON ROSA]

Exatamente Vagner , eu criei esse post quando passei por esse problema , no final das contas o erro estava na rede do cliente e para piorar o dbf estava corrompido alem de fazer varias considerações no sistema que os amigos aqui postaram .

[aferra]

mais alguns dados...

DbAppend( [<lUnlockRecords>] ) --> NIL

argumentos

<lUnlockRecords>

Defaults este parâmetro para T.. (true). Isso faz com que todos os bloqueios de registros pendentes estabelecidos com RLOCK () ou DbRLock () ser lançado antes de um novo registro é anexado ao banco de dados. Passe f. (false) para manter todos os bloqueios de registro intacto.

retorno

O valor de retorno é sempre nulo.

Descrição

A função DbAppend () adiciona um novo registro para o fim do banco de dados na área de trabalho atual. Use uma expressão alias para acrescentar um registro em uma área de trabalho diferente.

Todos os campos do novo registro são preenchidos com dados vazias de seus respectivos tipos de dados. Ou seja, campos de caracteres são preenchidos com espaços em branco, campos Data conter datas vazias, campos lógicos contêm f. (false) e campos numéricos de zero. Campos de memorando conter uma cadeia nula ("").

A função DbAppend () é garantido para adicionar um novo registro quando o arquivo de banco de dados é aberto para acesso exclusivo pelo aplicativo. Isto, no entanto, raramente é o caso. Em um ambiente multi-usuário, bancos de dados são normalmente aberto para acesso compartilhado. Como resultado, DbAppend () tenta bloquear o novo registro de modo que nenhum outro usuário pode alterá-la durante a operação. Se este bloqueio falhar, não há nenhum registro novo disponível para a aplicação. Em vez disso, o NetErr function () é definida para T.. (true) indicando uma falha de bloqueio o novo registro. Uma falha deste tipo pode acontecer, por exemplo, quando outro aplicativo tenha obtido um bloqueio de arquivo antes de DbAppend (). Tal condição de erro é normalmente tratada se NetErr () é verificada após DbAppend ().

Se DbAppend () travou com sucesso o novo registro, todos os outros registros bloqueios definidos no banco de dados são liberados por padrão. Para manter pendentes bloqueios de registro no local, o valor f. (false) deve ser passado para DbAppend ().

em resumo.

para acrescentar um novo registro

dbAppend( .F. )

IF neterr()

? "xi não travou"

else

replace ......

endif

para atualizar um registro

IF Rlock()

dbSetOrder( 0 )

replace ....

dbCommit()

dbUnLock()

dbSetOrder( <oldIndex> )

ELSE

? "xi não travou"

ENDIF

para deletar um registro

IF Rlock()

dbSetOrder( 0 )

DbDelete()

dbCommit()

dbUnLock()

dbSetOrder( <oldIndex> )

ELSE

? "xi não travou"

ENDIF

Claro que usando as função de "aguardar", que todos devem ter, mensagens padronizadas e por ai...ahhh e tem mais uma coisa, que dá um trabalho enorme é vc verificar a necessidade de ficar abrindo tantos dbf´s em modulos por exemplo, abri o cadastro de cliente e ai eu abro o de movimento de receber de produto de venda isso tb é um pouco furado melhor é vai cadastrar abra somente o que for de necessidade para cadastrar, estou consultando o cliente abra os dados do cliente, precisa ver o que ele comprou abra o movimento de vendas consultou feche e assim por diante, alem de ficar rápido ( na maioria dos casos ) diminui o fluxo de dados na rede deixando o sistema mais "leve".

e volto a dizer, o que já disse acima, o erro sempre é do programador kkkkkkkkkkkkkkk

[aferra]

um Adendo, o que percebi também, pelo menos o que ocorreu comigo, é que na troca de xharbour pelo harbour, alguns arquivos .fpt estavam "BUGADOS" na harbour, mas que no xharbour não apresentavam erros e justamente nesses arquivos é que corrompia os índices em harbour.

[oribeiro]

Obrigado Alessandro e Vagner,

Vou ajustar os meus comandos DbAppend(), DbDelete() e Replace de acordo com as suas sugestões.

Um abraço,