Página 1 de 2
No. do pedido repetido
Enviado: 15 Out 2013 16:40
por 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
No. do pedido repetido
Enviado: 16 Out 2013 11:07
por Toledo
Marcos, resta saber o que acontece depois do "replace pedido with SPEDIDO".
Abraços,
No. do pedido repetido
Enviado: 16 Out 2013 21:11
por 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
No. do pedido repetido
Enviado: 17 Out 2013 13:58
por 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.
No. do pedido repetido
Enviado: 17 Out 2013 23:10
por marcos.gurupi
Vlw pela dica. Amanha vou implantar a alteracao na empresa e observar...
Posso usar dbskip(0) ?
No. do pedido repetido
Enviado: 18 Out 2013 11:33
por ANDRIL
Após o replace, tente comitar os dados no HD com DbCommit().
Ate+
No. do pedido repetido
Enviado: 18 Out 2013 18:32
por 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 ?
No. do pedido repetido
Enviado: 28 Out 2013 09:11
por 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
No. do pedido repetido
Enviado: 28 Out 2013 23:54
por 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.
No. do pedido repetido
Enviado: 29 Out 2013 06:24
por 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.
No. do pedido repetido
Enviado: 29 Out 2013 10:02
por 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
No. do pedido repetido
Enviado: 30 Out 2013 00:24
por 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.
)
No. do pedido repetido
Enviado: 30 Out 2013 01:40
por 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
No. do pedido repetido
Enviado: 30 Out 2013 08:04
por 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!
No. do pedido repetido
Enviado: 30 Out 2013 14:21
por 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.