retornar ip que bloqueou o registro/arquivo

[Fernando queiroz]

Resumindo o problema

LOCK O REGISTRO
EDITA OS DADOS
GRAVA OS DADOS NO DBF
UNLOCK O REGISTRO

é só mudar para

EDITA OS DADOS
LOCK O REGISTRO
GRAVA OS DADOS
UNLOCK O REGISTRO

ai acaba todo o problema que ele esta tendo, se o usuario pegar para edicao nao fica travado

obs: no meu tempo de DBF eu tinha um campo QUEM_BLOQUEIA para avisar ao outro usuario quem ta bloqueando

[Itamar M. Lins Jr.]

Olá!
Mais uma coisa que vocês estão equivocados.
O LETODBf não faz milagres.
O DBF é rápido por natureza, muito rápido, sólido, testado e aprovado por todos nós.
Não é o LetoDB que vai fazer o DBF ficar mais rápido, o DBF é assim rápido quando usado LOCAL sem compartilhar, arquivos abertos em modo EXCLUSIVO!

O quê o LetoDBf faz é transformar/MANTER a VELOCIDADE do uso EXCLUSIVE usando SHARED ! Nada mais.

E o LetoDBf tem mais outros recursos interessantes.

LetoDBf, não vai resolver problemas de ENGENHARIA de RLOCK/FLOCK. Errado fica errado com LetoDBf ou sem LetoDBf.

Código: Selecionar todos

      TimeOut = -1             -    Connection timeout in seconds, -1 means infinite wait.
                                    This timeout determine, how long a write to network/ wait for requested workarea
                                    will wait to succeed, before the thread for the connection give up.
                                    If used: Zombie_Check, this value shell be shorter than that.
      Zombie_Check = 0         -    Time in seconds, that a client must be quiet ( no activity ), before
                                    a 'are you healthy' query (ping) is send from server, to verify it's not a
                                    dead/ unplugged connection. ! Application must be linked multi-thread ( '-mt' ) !,
                                    else these checks cannot be done.
                                    As 3 times for a given interval a check is done, a zombie can be 1/3 time
                                    longer 'dead', e.g. 60 ==> max. 80 seconds 'dead' before detected.
                                    Such connection will be shut down, opened files and locks are reset-ed.
                                    If set to 0 [ default ], these checks are diabled.

Então conforme está ai, o LetoDBf pode checar a conexão e resetar o locks. (Não usei ainda)
Além dessa opção tem outra de restart do serviço do LetoDBf no windows.

Código: Selecionar todos

C:\dev\letodbf\bin>net stop letodbf_service

O serviço de LetoDBf_Service letodb.ini foi finalizado com êxito.

C:\dev\letodbf\bin>net start letodbf_service
O serviço de LetoDBf_Service letodb.ini está sendo iniciado.
O serviço de LetoDBf_Service letodb.ini foi iniciado com êxito.

Veja ai que tem como saber IP/DBF aberto por qualquer usuário logado pode olhar fonte(funções) do programa (console.exe do leto)e colocar DIRETO no seu .EXE!

Sim e pode derrubar a conexão.

Saudações,
Itamar M. Lins Jr.

[Itamar M. Lins Jr.]

Olá!
Tem como derrubar a conexão...

Saudações,
Itamar M. Lins Jr.

[clodoaldomonteiro]

Questão é o seguinte, até aconteceu comigo e Quintas me ajudou a resolver e entender.
Se estou trabalhando em REDE, não devo abrir tabela em modo exclusivo e no ato de salvar os dados na inclusão ou na atualização de dados, fazer os devidos FLock(), RLock() e os "UnLock".
Deve ser simples assim mesmo, pois quanto mais a gente enfeita, mais feio fica.
Segue Exemplo que Quintas me passou, com poucas alterações:

Código: Selecionar todos

Function Main()

...
...

      cc := 1

      Do While .t.

         If ze_RecAppend( .t. )

            ze_RecReplace( ArrayCamposNomes, Alias() )

            ze_RecUnlock()

         Else

            msg := '[EMP] Não consegui gravar este registro, ocorreu um problema na Rede ou na abertura da tabela:' + Alias()
            msg += CRLF + 'Quantidade de tentativas: ' + Str(cc, 4)
            msg += CRLF + 'Deseja tentar novamente?'

            If MsgYesNo( msg )
               Loop
            Endif

         Endif

         Exit

         cc++
         
      EndDo

...
...
Return NIL

Arquivo com rotinas de uso em Rede:

Código: Selecionar todos

/*
ZE_REDE - ROTINAS PARA USO EM REDE
1995.04 José Quintas
*/
#pragma -w0
#pragma -es0

#include "inkey.ch"
#include "GAS.ch"

FUNCTION ze_RecLock( lForever )

   LOCAL nCont := 1

   Default( @lForever, .T. )
   //wSave( MaxRow() - 1, 0, MaxRow(), MaxCol() )
   DO WHILE .T.
      IF rLock()
         EXIT
      ENDIF
      //Mensagem( "Aguardando liberação do registro em " + Alias() + "... Tentativa " + lTrim( Str( nCont ) ) + iif( lForever, "", ". ESC cancela" ) )
      IF Inkey( 0.5 ) == K_ESC .AND. ! lForever
         EXIT
      ENDIF
      nCont += 1
   ENDDO
   //WRestore()
   SKIP 0

   RETURN ( rLock() )


Procedure ze_RecReplace(aRep, cAlias )
   Local i, msg

   FOR i := 1 TO FCount()
      msg    := FieldName(i)
      aRep[i] := M->&msg.
      &cAlias->&msg. := aRep[i]
   NEXT

   &cAlias->Flag := DtoC(Date()) + '|' + Time() + '|' + AllTrim(UserNic)
   
   Return

FUNCTION ze_RecAppend( lForever )

   LOCAL nCont := 1, lOk := .F., telaSave

   Default( @lForever, .T. )

   telaSave := SaveScreen(0, 0, MaxRow(), MaxCol() )

   DO WHILE .T.

      APPEND BLANK

      IF ! NetErr()
         lOk := .T.
         ze_RecLock()

         EXIT

      ENDIF

      DBOX("Liberando do arquivo: " + Alias() +;
       "|... Tentativa " + LTrim( Str( nCont ) ) +;
       IIf( lForever, "", "|[ESC] cancela" ), Int(MaxRow()/2),,, NAO_APAGA, "AGUARDE!")

      IF Inkey( 0.5 ) == K_ESC .AND. ! lForever
         EXIT
      ENDIF

      nCont += 1

   ENDDO

   RestScreen( 0, 0, MaxRow(), MaxCol(), telaSave)

   SKIP 0

   RETURN lOk


FUNCTION ze_RecDelete( lForever )

   LOCAL lOk := .F.

   Default( @lForever, .T. )
   IF ze_RecLock( lForever )
      DELETE
      ze_RecUnlock()
      lOk := .T.
   ENDIF

   RETURN lOk

FUNCTION ze_RecUnlock()

   SKIP 0
   UNLOCK

   RETURN NIL

Espero ter ajudado,
Abraços.

[Eduardo Pinho]

por Itamar M. Lins Jr. » 22 Jun 2023 17:49

Usando DBF em rede, a TRAVA(LOCK) só ocorre durante a GRAVAÇÃO(REPLACE) seguido do UNLOCK, não fica a cargo do usuário decidir isso.
ISSO É BÁSICO DO BÁSICO EM REDES.

Sei que o assunto já deve ter morrido mas feriado sem nada pra fazer resolvi dar pitaco na discussão.. rs..
Concordo com Itamar, e também procuro sempre fazer assim.. Só Lock/replace/unlock na hora de gravar mesmo, decimos de segundo..

Só que nunca é tão simples. Também acho importante que quando um está alterando, outro NAO PODE alterar, senao alguem vai perder a digitacao, e o que é pior, 1 deles pode nem perceber que perdeu o que acabou de alterar.

Lá na empresa volta e meia acontecia isso, porque na tela de edição estava os dados de antes (que eram salvos, cancelando a alteração do outro). Logo, bloquear antes durante a edição, parece uma solução óbvia. Mas resolvia esse e causava outros problemas, como impedir os modulos automaticos da empresa de gravar alguma coisa, fora o cara se ausentar e largar o trem bloqueado.

Lá eu resolvi criando uma tabela separada só com o campo identificador (codigo/id/etc..), e fazendo o bloqueio nessa tabela. Assim eu impeço 2 usuários de alterar ao mesmo tempo e o registro principal na tabela principal fica liberado pras alterações automaticas do sistema que podem acontecer a qualquer momento.

É meio tosco mas quando tem um problema pra resolver, as vezes (ou quase sempre) vamos onde dá menos trabalho, menos linhas de código pra alterar, (vulgo bacalhau.. kkkk).

O problema do cara largar bloqueado ainda pode acontecer, mas não é tão frequente e eles se viram perguntando... É um problema menor.. Mas um deles perder a digitação e nem saber que perdeu, ou o sistema não poder realizar alguma alteracao silenciosa, era bem pior...