PC Toledo

Enviado: **14 Jun 2017 14:25**

Grato por mais retornos.
Sim, é o mesmo sistema e a mesma versão em todas as lojas.
Esta loja em questão que da problema é a MATRIZ, só ocorre na tabela de ORÇAMENTOS, não é a de maior movimento, é a segunda, tem uma filial que tem mais movimentação ao mesmo tempo.
Vou testar, refazendo a tabela criando uma nova para orçamento.
Quanto a rotina, não há falha, inclusive outros fontes do mesmo sistema gravam da mesma forma e no entanto nada ocorre errado, apenas nesta tabela.
Devido a esta falha, preparei o fonte de forma diferente, para gravar unicamente um computador por vez e mesmo assim continua igual.
Detalhe, não ocorre isto em todas as gravações, salve lá algum dia, o que eu notei é que o indice é afetado, tenho sempre que ordenar esta tabela em questão para resolver o problema.
Só falta eu colocar um NOBREAK em cada computador, para ver se resolve.

Grato novamente a todos.

Enviado: **14 Jun 2017 15:42**

Só falta eu colocar um NOBREAK em cada computador, para ver se resolve.

Com certeza nobreak não resolve, porque pelo que mostrou tem informações misturadas.

Talvez esteja olhando a rotina errada, ou já decidiu que é APPEND errado e não procura outra coisa.

Eu diria o seguinte:
Tá com problema nessa rotina, tá quebrando a cabeça com ela?
Tá mais que na hora de fazer uma revisão e deixar a rotina decente.

GravaOrc()... não tem limite de 10 letras... GravaOrcamento()

Parâmetros aTipo e aModo?
aModo é muito mais importante, deveria vir em primeiro lugar.

DBCOMITA... Que troço doido é esse?
Porque só desbloquear se for alteração?

Passar parâmetro INCLUIR/ALTERAR....
Eita coisa fácil de ter problemas.
Em último caso, use #define
Por acaso já pensou que o problema pode ser a palavra "INCLUIR" vindo errada?
Se a rotina só pode ser chamada por incluir ou alterar, bastava um parâmetro .T. ou .F. pra dizer se inclui ou não.

Sua mesma rotina passando por uma transformação visual

Tem uma coisa muito importante que pode passar desapercebida aí....
Se o programmers notepad está configurado pra colorir os comandos, porque alguns WITH estão de uma cor e outros de outra?
Lógico... algum caractere diferente está aí no fonte.
Se foi do copiar/colar do fórum ou não, não faço idéia, mas algum caractere estranho existe no fonte.

Se faz diferença usar campo := valor, ou REPLACE eu não sei, mas sempre usei assim e vou continuar usando.
Vamos acabar fazendo tudo de uma vez pro MySQL, então porque não no DBF?

Também não entendi porque a rotina está em separado, talvez melhor rever a rotina principal.
Se essa rotina usa variáveis que nem existem nela.... como considerar que as variáveis estão corretas?

Aliás, simplificando é isso: a rotina está certa, mas se os parâmetros/informações que chegam nela estão corretos, não se sabe.
Deve analisar o conjunto, e não apenas a rotina.

Boa sorte.

Enviado: **14 Jun 2017 16:07**

Esquisito... Chr(160) não é tab, pelo menos o Chr(9) que eu conheço como tab.

Enviado: **15 Jun 2017 18:27**

Ola!

infelizmente o Harbour parece ter desandado nessa direção.

Veja o trabalho do Rodrigo Moreno. Ele criou os dois drivers no [x]Harbour, para MySQL, depois abandonou e só trabalha com Postgree.

Código: Selecionar todos

 * PostgreSQL RDBMS wrapper header.
 *
 * Copyright 2010 Viktor Szakats (vszakats.net/harbour) (GC support)
 * Copyright 2003 Rodrigo Moreno rodrigo_moreno@yahoo.com

Quanto ao outro problema, se usas mapeamento isso sempre irá ocorrer.
A rede falha mesmo, quando mapeada. Deve usar outras opções. Mapeamento = problemas eternos, por isso o pessoal fala mal do DBF. Mas com NetIO, LetoDB, ADS, etc é só escolher uma das opções, e se livrar desse problema.

Saudações,
Itamar M. Lins Jr.

Enviado: **15 Jun 2017 21:48**

Eu também trabalho com mapeamento, sem problemas.

Apesar de misto com MySQL, o pesado ainda está em DBF via mapeamento.
Nenhum problema com DBF, estou fazendo a migração pra MySQL apenas porque quero sair de DBFs.

Acho que só restaram 2 clientes que usam exclusivamente contabilidade, que só tem DBF.
Nos demais, é o ambiente misto.

Enviado: **15 Jun 2017 22:01**

Complemento: o que eles usam como servidor:

Sinceramente não sei, só sei de alguns:
Servidor: Windows Server, Windows 8, Windows 7, e outros que não faço idéia
Terminais: de XP a W10

Eu apenas oriento como instalar o aplicativo e/ou criar atalho nos terminais, se precisar.
Não faço idéia do que tem em cada um, somente de alguns.

Enviado: **17 Jun 2017 08:26**

Varios dias desde a mudança e nenhum erro hehehehe

O que eu acho que estava acontecendo:
- O cliente eh um supermercado com 7 cxas;
- Ha um cxa com problema de rede. Nao sei se cabo ou placa de rede. Sei que sabemos do problema e sabemos qual o caixa. Do nada a rede cai ocasionando erro no sistema.
- Qndo da erro nesse bendito cxa, o erro se propagava por toda a rede atingindo os outros cxas em cadeia

suponho: caixa com problema inseria um registro com DbAppend() e logo em seguida o sistema era derrubado pelo problema da rede. Como nao houve destravamento desse registro nesse caixa, os outros tentavam no mesmo miléssimo de segundo inserir um novo registro na mesma tabela mas nao conseguia (eu so testava o dbappend uma vez).

Agora, insistindo no DbAppend() até da certo, o erro sumiu (pelo menos nao tive mais news (kkk) dele)

Enviado: **17 Jun 2017 17:21**

Cada um tem sua forma e preferência, eu faço assim

Código: Selecionar todos

  
IF cOperacao = "I"
   APC01->( DbAppend() )
   lAppLock := ! NetErr()
ELSE 
   lAppLock := APC01->( DbRLock() )
ENDIF 		
   
IF lAppLock //inclui e/ou atualiza um registro
.....
ENDIF

Enviado: **17 Jun 2017 19:16**

Vixe... nem percebi.... acabei considerando as mensagens desde 2015 pras respostas.

Agora, insistindo no DbAppend() até da certo, o erro sumiu (pelo menos nao tive mais news (kkk) dele)

Mas mexeu no Append() ou também no SKIP 0/UNLOCK

Enviado: **17 Jun 2017 20:28**

O mesmo que o Quintas:

Agora, insistindo no DbAppend() até da certo, o erro sumiu (pelo menos nao tive mais news (kkk) dele)

Também queria saber antes do unlock ou dbunlock usou skip 0, dbskip(0) é útil saber pra sabermos se todos estamos falando a mesma lingua.

Enviado: **17 Jun 2017 22:44**

Apenas substitui os meus DbAppend() pela função postada pelo Itamar (se nao me engano).

Código: Selecionar todos

SELECT TITULOS
MyDbAppend()
replace CODEMP with vCODEMT ,;
		  TIPDOC with vTIPDOC ,;
        DESPRZ with vDESPRZ ,;
...

DbCommit()
DbUnlock()

***************************
Function MyDbAppend(cAlias)
***************************
Local nTentativas := 1

hb_default(@cAlias,Alias())   

Do While .T.
  (cAlias)->(DbAppend())
   If neterr()
		nTentativas++
		MsgRun3( "Tentando Incluir Registro!", "Aguardando liberacao do Arquivo " + ['] + ALIAS() + [!' ] + "Aguarde...", "Tentativa Nr " + StrZero( nTentativas, 6 )  )
      InkeyGui(100)
   Else
   	If nTentativas > 1
			FechaMsg()
		Endif

      Exit
   EndIf
EndDo

Return .T.

Enviado: **18 Jun 2017 00:13**

Acabou usando um mix, a rotina do Itamar, e mais o tempo de espera que mostrei.
Na prática acho que é isso que faz diferença, igual aquilo do Clipper usar 100% de CPU.
Se não libera tempo pro Windows fazer o trabalho dele, coisas estranhas acontecem.... rs

Enviado: **18 Jun 2017 10:11**

Quintas,

Se não me engano InkeyGui(100) é outro tipo de inkey, que nesse caso não sobrecarrega o processo windows, eu tenho essa função

Enviado: **18 Jun 2017 10:48**

Janio,

Apenas uma função mais genérica aproveitando a sua, que neste caso atende Inclusão, Alteração ou Exclusão de registro, com detalhe no retorno lógico da função que pode ainda sim ter algum tratamento

Parâmetros de entrada I-inclusão (default), A-Alteração, D-Deleção e alias opcional, saída .T. ou .F. se conseguiu ou não append/lock da tabela em uso

Tem que controlar o contador nTentativas para não ficar em um loop infinito, até 20 tentativas sai com .F.

Apenas uma ideia:
Nota: as funções MsgRun3 e FechaMsg podem ser substituídas pela preferência do programador

Código: Selecionar todos

FUNCTION AppendLock( cOperacao, cAlias )
LOCAL lAppLock := .F., nTentativas := 1
   hb_Default(@cOperacao, "I" )
   hb_Default(@cAlias, Alias() )
   DO WHILE ! lAppLock
      IF cOperacao = "I"
         (cAlias)->( DbAppend() )
         lAppLock := ! NetErr()
      ELSEIF cOperacao = "A" .OR. cOperacao = "D"
         lAppLock := (cAlias)->( DbRLock() )
      ENDIF
	    IF ! lAppLock
	       MsgRun3( "Tentando gravar Registro!", "Aguardando liberacao do Arquivo " + ['] + ALIAS() + [!' ] + "Aguarde...", "Tentativa Nr " + StrZero( nTentativas, 6 )  )
	       nTentativas ++
	       IF nTentativas > 20
	          EXIT
	       ENDIF
          InkeyGui(300)
      ENDIF		 
   ENDDO
   IF nTentativas > 1 
      FechaMsg()
   ENDIF 
RETURN lAppLock

Enviado: **18 Jun 2017 14:00**

Tem que controlar o contador nTentativas para não ficar em um loop infinito, até 20 tentativas sai com .F.

Péssima idéia.
Senão vai ter que acrescentar milhões de linhas no aplicativo pra controlar isso e muito mais.
No máximo a opção de infinito .T. ou .F. , para casos isolados.

Situação:
Confirma o pedido, baixa estoque, lança no financeiro, etc.
Se lock não for infinito, pode ficar numa situação parcial.
E aí... fonte e mais fonte pra situações variadas.

PC Toledo

DbAppend falha

DbAppend falha

DbAppend falha

DbAppend falha

DbAppend falha

DbAppend falha

DbAppend falha

DbAppend falha

DbAppend falha

DbAppend falha

DbAppend falha

DbAppend falha

DbAppend falha

DbAppend falha

DbAppend falha

DbAppend falha