PC Toledo

Pequena correção:

Já mexi sim, pra instalar o ODBC do MySQL, e o run-time do Visual C que o ODBC precisa.

NÃO TENHO nenhuma reclamação de DBF, mas agora prefiro MySQL.

Sinceramente.... estou com medo de alterar o aplicativo da imobiliária pra MySQL e começar a ter problemas.
É que a lógica do aplicativo é complicada, e não sei se o MySQL vai dar conta do jeito que está.
Mas com certeza, a primeira coisa que fiz foi deixar igual meu aplicativo, no tratamento de rede e tudo mais.

Acho que a última reindexação lá foi em 2019, antes da pandemia, porque sou eu quem reindexa, e geralmente na hora do almoço, quando ninguém está usando.
Cheguei a passar por lá, mas não foi na hora do almoço, então não deu pra reindexar.

Pensei aqui....
Faça um teste diferente.
Diz que o problema é que não grava, e não exatamente o append.

Coloque pra registrar o REPLACE depois do APPEND, incluindo RecNo(), Eof(), LastRec(), etc.

Quando falhar, verifique nesse histórico informações sobre o registro.

De repente não é que falha, é porque outro terminal escreve encima do append do terminal anterior.
De repente não é o W7 que falha, e sim outra máquina, que acaba gravando encima.

Outra coisa que sugere isso....

Está testando o bloqueio de registro, e não o append.
Isso significa que se o append falhar, vai tentar bloquear outro registro, o último, justamente o que vai estar sendo usado em outra máquina, e por isso não consegue bloquear.
Assim que a máquina gravar e liberar, a outra já vai gravar encima, substituindo o conteúdo.
Então... não seria que não gravou, mas sim que foi "coberto" pelo de outro terminal.

Porque isso só acontece na máquina com W7 ?
Sabe-se lá porque.
De repente a máquina com W7 também é mais rápida, e não acontecia antes, por questão de velocidade.

Seja o que for, esse teste está errado, e é a primeira coisa a ser corrigida.

Só aproveitando o acontecimento....

De repente, muda pra Harbour e os problemas aumentam.
E o problema era uma coisa desse tipo, que no Harbour vai ser mais rápido e liberar o append mais rápido, pronto pra ser regravado.

Convém chamar a atenção nisso.
De repente, muitos que tiveram problema foi por coisas desse tipo.

É fácil converter pra Harbour?
Depende dos fontes.
Num caso desses, os problemas aumentariam, mas não por problema do Harbour, porque havia problema nos fontes.

É por isso que eu digo:

Aproveita que os fontes Clipper/Harbour são compatíveis, vai ajustando SEM SAIR DO CLIPPER, e eventualmente vai compilando com Harbour e testando.
Com mesmos fontes, pode ir pro Harbour e voltar ao Clipper à vontade.
Aproveita pra dar uma geral.
Os fontes estarão sempre funcionando e prontos pra uso, seja Clipper ou Harbour.
E quando tudo ok, basta colocar a compilação com Harbour, e pronto.

Faz 20 anos que o Harbour existe, se não trocou até agora, não precisa trocar do dia pra noite.
Vai tranquilo, ajustando fontes, testando, deixando sempre em uso com Clipper mesmo.... alguns meses a mais ou a menos não faz diferença, esperou 20 anos, espera mais alguns meses.
De qualquer jeito, tudo vai ficar melhor, então sem pressa.

Mas de preferência, NÃO CRIE fontes diferentes pro Harbour durante a migração.
Use sempre os mesmos, porque sempre estarão atualizados, e sempre testados/em uso pelo cliente.
Com isso não perde nada do que fizer.

Já se criar fonte diferente pra Harbour.... pode acabar jogando tudo fora, porque pode ter atualizado os fontes Clipper.... e os do Harbour não servirem mais.

Ok José,

Muito obrigado aí pelas orientações e dicas!

Valeu!

Olá!

JoséQuintas escreveu:Vai continuar sem teste se append funcionou.
Tem que ser pelo menos isto:
01 lOk := .F.
02 nCont := 0
03 DO WHILE nCont >= 20
04    IF dbAppend()
05       lOk := .T.
06       EXIT
07    ENDIF

Isto na linha 4 não funciona. DbAppend() sempre retorna NIL.

O correto é sempre fazer o DbAppend() e em seguida testar NetErr(). Se o DbAppend() conseguir incluir um novo registro, ele próprio já trava este novo registro e NetErr() é setado para False. Não precisa fazer RLock() ou DbRLock() depois de DbAppend() bem sucedido. RLock() ou DbRLock() liberam os locks existentes antes de tentarem fazer um novo. Se o DbAppend() conseguir inserir um novo registro, ele vai tambem travar. Se em seguida emitir um RLock() neste registro já travado, ele vai ser liberado. Será que o RLock() emitido vai travar exatamente o mesmo registro?

Mario Mesquita escreveu:Pra dar append na tabela, tem que estar travado com Flock(). Está assim no seu sistema?

Isto não é verdade... e acho que ninguém conseguiria trabalhar numa rede com alguns poucos terminais...

alxsts escreveu:Isto na linha 4 não funciona. DbAppend() sempre retorna NIL.
O correto é sempre fazer o DbAppend() e em seguida testar NetErr()

Realmente, fui querer passar uma rotina mais simples, e me confundi.
Use o fonte que passei antes, ajuste pras suas mensagens.
E como é Clipper, inclua a parte da OSLIB.

Olá!
DbAppend() retorna Nil no Clipper. No Harbour retorna .T. ou .F.
Saudações,
Itamar M. Lins Jr.

Mesmo assim, como é referente ao Clipper, melhor o método antigo que funciona em Clipper e em Harbour.
Assim usa o mesmo fonte nos dois.

Ou aquelas funções RecAppend(), RecLock(), RecUnlock()
Essa é a vantagem delas: pode modificar o aplicativo inteiro, e depois trata-se apenas de mexer nas 3 funções pra alterar tudo de uma vez.

Olá!

Itamar M. Lins Jr. escreveu:DbAppend() retorna Nil no Clipper. No Harbour retorna .T. ou .F.

Só para constar, no xHarbour, DbAppend() se comporta como no Clipper, retornando NIL. É o que consta no "xHarbour Language Reference Guide (Version 1.1)". Não testei pois não tenho ele instalado.