No. do pedido repetido

[marcos.gurupi]

Caros,
Parece que estamos no forum do velho e bom clipper, mas fiz a atualizacao do meu sistema onde os terminais trabalha com XP/Win 7 e o servidor de dados é win2003 server, acontece que apos a atualizacao do sistema tudo estava indo bem... derrepente os no. dos pedidos comecaram a repetir, verifiquei a rotina e estava normal (sempre uso a mesma rotina), modifiquei (segue abaixo a modificação), tudo parecia bem mas derrepente alguem faz um pedido e por acaso nao consegue visualiza-lo e na seguencia se outro vendedor fizer o pedido os no. ficam repetidos ai vira uma bagunça. Alguem saberia me dizer se é algo entre o xhb 1.0.0 q estou usando e o win2003 server ?

Segue abaixo a rotina q uso atualmente para definir no. do pedido:

Código: Selecionar todos

Select 12        // AREA DE PEDIDOS
ordsetfocus(1)   //ORDEM DE PEDIDO
dbgobottom()  
sPedido:=Pedido+1
DO WHILE .T.
	DbSeek(sPedido)
	If Found()
	   sPedido+=1
	   Loop
   Endif
   IF TRAVARQIVO(5)
		dbappend()
      replace pedido     with SPEDIDO

Ou sera q o FLOCK nao estah travando o arq. corretamente ?

Código: Selecionar todos

FUNCTION TRAVARQIVO(tempo)
DO WHILE TEMPO > 0
   IF FLOCK()
      RETURN .T.
   ENDIF
   TEMPO = TEMPO - 1
ENDDO
RETURN .F.

NOTA: Para nivel de informacao: a rede está instalado com dominio

[Toledo]

Marcos, resta saber o que acontece depois do "replace pedido with SPEDIDO".

Abraços,

[marcos.gurupi]

Vc quer q eu poste o restante do codigo? Eh que no final destravo o arq e volto para tela de vendas. Fica parecendo que a funcao flock() nao esta travando o arq. Por isso outros terminais pegam o mesmo no. De pedido causando a confusao. Estranho que lah estah rodando a versao antiga com xhb 0.97 e tudo corre nromalmente, quando eu coloco o sistema novo comeca bem e de uma hora pra outra o no. Pedido fica repetido

[JoséQuintas]

depois do replace, use:
SKIP 0
UNLOCK

O SKIP além de movimentar o registro, salva o conteúdo anterior.
O SKIP 0 é usado como fake, não movimenta mas salva.

[marcos.gurupi]

Vlw pela dica. Amanha vou implantar a alteracao na empresa e observar...

Posso usar dbskip(0) ?

[ANDRIL]

Após o replace, tente comitar os dados no HD com DbCommit().
Ate+

[marcos.gurupi]

Caro Jose a sua sugestao nao funcionou. Usei assim:

Código: Selecionar todos

   SELECT 12   //  ARQUIVO DE PEDIDOS
   ORDSETFOCUS(1)
   DBGOBOTTOM()
   SPEDIDO:=PEDIDO+1
   DO WHILE .T.
      dbseek(sPedido)
      If Found()
         sPedido+=1
         Loop
      Endif
      IF TRAVARQIVO(5)
         dbappend()
         replace pedido     with SPEDIDO


         Skip 0
         dbcommit() //TAMBEM NAUM FUNCIONOU
         dbunlock()
      ELSE
         LOOP
      ENDIF
      EXIT
   ENDDO

Caro Andril eu jah havia testado com o dbcommit() e tb nao adianta. Essa rede os terminais estao usando o XP e o servidor eh win2003 server com dominio, serah q pode ser algo relacionado ao dominio ?

Ou mesmo o xhb q estou usando tem alguma incompatibilidade com o win2003 server ?

[paiva_dbdc]

BOM dia

ainda esta com problema ?

uma vez aconteceu comigo e para este usuario tinha que fechar o arquivo e depois abrir ai resolveu.

era como se fosse falha de rede


Paiva

[marcos.gurupi]

Caro amigo, ainda nao resolvei, estou precisando atualizar o sistema no cliente mas nao posso fazer por causa do problema. Conversei com o adm da rede mas nao acredito q irah adiantar.

Sobre fechar o arq e abrir novamente eu terei q estudar o caso, eu trabalho sempre com os arquivos abertos. Ganho em performace. Obrigado pela dica.

[sygecom]

Marcos,
Quem sabe mude a lógica, eu particularmente uso de outra forma, tenho uma tabela chamada sequencia que guarda o ultimo numero usado, quando quero o proximo numero chamao essa tabela localizo o tipo de cadastro travo o registro acresento mais um dou um commit e libero o registro e apartir dai já se sabe que numero usar.

[paiva_dbdc]

Marcos Bom dia

e´Justamente o que faço + para este usuario especifico NAo funcionava
acho que a rede NAo atualizava de imediato entao dava problema

a unica solucao foi fechar e abrir o arquivo toda vz

paiva

[marcos.gurupi]

Leonardo obrigado pela dica mas a sua sugestao esta usando a mesma logica que eu uso com a diferenca que vc usa um arq. que controla a seguencia, se o problema e que a rede nao atualiza (mesmo usando o dbcommit) imediatamente usando um arq. separado para gerenciar a numeracao eu ainda teria o problema da nao atualizacao instantanea.

Paiva, vou tentar usar a sua sugestao. Vai ser complicado principalmente pq a minha estrutura eh usada para arquivos abertos. Vou estudar aqui. Se funcionar com vc acredito que vou ter sucesso. Tomara que nao abra um buraco em outro lugar. )

[MARCELOG]

Ola Marcos!
Em rede tudo deve ser controlado.
Experimente travar o arquivo, definir e gravar spedido, liberando o arquivo.
O tempo entre a definicao de spedido o travamento do arquivo e gravacao do registro em rede nao comporta a suposicao de inexistencia de mudanca no infimo lapso temporal.
MarceloG

[ANDRIL]

Já que verificou toda sua lógica e "esta certa", parta para a configuração do servidor. Peça para que o administrador de rede desative o cache de disco para ver se resolve. Em outras versões do windows quando ocorrem problema "semelhante" consegui contornar desta forma.

Boa sorte!

[MARCELOG]

Veja bem Marcos.
O usuário X efetua a leitura do arquivo e define a variável sPedido.
Supondo que número lido seja 100, a variável sPedido foi definida como 101.
Assim, faz-se uma tentativa de bloqueio do arquivo e inserção de sPedido (101).
Todavia, noutro terminal, o usuário Y realiza a mesma operação e define sPedido como sendo 101.
Porém, mais rápido que o usuário X, o usuário Y consegue o travamento do arquivo e inserção do valor de sPedido (101), liberando o arquivo.
Assim, como o arquivo está liberado, o usuário X consegue o travamento e inserção do seu valor de sPedido (101), que não foi modificado, liberando o arquivo.
Dessa forma haverá a duplicidade que você não deseja.
A definição de sPedido deve se dar com o arquivo travado, impedindo a definição de sPedido por outros usuários (forma radical).
Quando não, a função de travamento de arquivo deve tentar o procedimento uma única vez.

MarceloG

PS: Provavelmente a sua função de travamento do arquivo tem quantidades de tentativas de bloqueio antes de retornar verdadeiro ou falso, ocasionando o problema.