PC Toledo

Amigos muito isoladamente falando, ou seja, dificilmente acontece, mas acontece em 2 clientes meus. apos feita a venda para um cliente vou gerar o financeiro para o mesmo, quando imprime a nota para o cliente assinar sai realmente a duplicata impressa abaixo do total da nota tento ai a confirmação que realmente foi gravada no arquivo financeiro a duplicata. Só que no final do dia quando fecha o caixa bomba cade a duplicata do cliente, some sem deixar vestigio ja fiz testes e mais teste e nada, ja ate tirei o pack na hora da reorganizacao deste arquivo e nao a vestigio do determinado registro, ai eu tirei uma logica q acho que em um determinada hora por sei la oq. outro registro sobreescreve o antigo, ou seja, ancho que o append nao esta montando um registro novo e sim travando o ultimo registro armazenado e sobreescrevendo com uma nova informação, oq fazer?

ancho que o append nao esta montando um registro novo e sim travando o ultimo registro armazenado e sobreescrevendo com uma nova informação, oq fazer?

Olá,
Acredito que se vc esta usando append blank em momento algum ele vai alterar um Registro que já existe, claro que vale lembrar que se vc tem esse sistema em Multi-usuario tens que fazer os devidos tratamento para rede. Agora ainda vc pode ter um usuario usando um DBU da vida e deletando um registro, ou seria ideal vc postar o codigo dessa sua rotina que esta dando o problema para nos poder dar uma analisada e quem sabe dar algumas dicas em cima do que vc já tem.

Abraços
Leonardo Machado

outro registro sobreescreve o antigo, ou seja, ancho que o append nao esta montando um registro novo e sim travando o ultimo registro armazenado e sobreescrevendo com uma nova informação, oq fazer?

Ao terminar a inclusão você executa um COMMIT?

E também precisa verificar se o append blank teve exito. Precisa verificar como vc está incluindo um novo registro. Se além do append blank, vc emite um rlock() (desnecessário), e não existe uma verificação do exito do append, com certeza o furo está por aí.
E é lógico, como citou o Maligno, commit sempre antes de destravar. Aliás seria mais providencial, um DbCommit().

Falar em COMMIT (traduzido para dbCommitAll()) é força de hábito pra mim. Queria dizer dbCommit(), que é melhor mesmo.

Vc coloca o número sequencial de lançamento? Algum controle desse tipo?
Veja sua rotina de inclusão.
Se ela depende de determinado número e esse é gerado pelo velho "pega o último número do arquivo e soma 1", ai pode estar seu problema.
Outra é liberar o registro atualiado antes do commit dos dados.

sygecom escreveu:

ancho que o append nao esta montando um registro novo e sim travando o ultimo registro armazenado e sobreescrevendo com uma nova informação, oq fazer?

Olá,
Acredito que se vc esta usando append blank em momento algum ele vai alterar um Registro que já existe, claro que vale lembrar que se vc tem esse sistema em Multi-usuario tens que fazer os devidos tratamento para rede. Agora ainda vc pode ter um usuario usando um DBU da vida e deletando um registro, ou seria ideal vc postar o codigo dessa sua rotina que esta dando o problema para nos poder dar uma analisada e quem sabe dar algumas dicas em cima do que vc já tem.

Abraços
Leonardo Machado

PREN->(dbappend())
DO WHILE Travar5("PREN"); inkey(.2); ENDDO
PREN->CODCLI := cCodcli
PREN->NRODOC := cCodped+"/"+iii
PREN->NRONOT := cCodped
PREN->DTAEMI := date()
PREN->DTAENT := date()
PREN->CODBAN := "001"
PREN->TIPDOC := cTipdoc
PREN->REFERE := cRefere
PREN->CODVEN := cCodven
PREN->COBRAD := cCodven
PREN->CAIXA := cCaixa
PREN->NROCAX := Pegacaixa()
PREN->SETOR := cSetor
PREN->ENTRACAX:= "S"
PREN->CARGA := cCarga
PREN->CHAVE := cCodped+"/1"+cCaixa
if cPrazo # "00"
PREN->DTAVEN := date()+val(PZO->VENPZO&ii)
PREN->DTAVOR := date()+val(PZO->VENPZO&ii)
else
PREN->DTAVEN := dDtabase
PREN->DTAVOR := dDtabase
endif
if (q = 1) .or. (nQq = 2 .and. q = 2)
if PZO->CENTAVOS == q
PREN->VALENT := nValDupl+nCentavos
PREN->VALORI := nValDupl+nCentavos
else
PREN->VALENT := nValDupl+nDif
PREN->VALORI := nValDupl+nDif
endif
else
if PZO->CENTAVOS == q
PREN->VALENT := nValDupl+nCentavos
PREN->VALORI := nValDupl+nCentavos
else
PREN->VALENT := nValDupl
PREN->VALORI := nValDupl
endif
endif
if !empty(cObs)
PREN->HISTORICO += "OBS.:"+cObs+chr(13)
endif
PREN->(dbunlock())
PREN->(dbcommit())


olha esta ai a funcao que tanto me deixa louco, olha esta funcao tem nada nda uns 8 anos que eu fiz e so agora é que esta dando este problema e é um caso isolado....

AHA
Exatamente o que eu citei.
Aquele dbappend() precisa ser testado.
Aliás um outro equívoco: O dbappend() (se não falhar) já trava o registro, não precisa travar depois com rlock().

Da maneira como está, se o dbappend() não conseguir exito, o sistema não vai retornar erro, pois existe um rlock() em seguida.

tente assim

Será que botaram trago no meu chimarrão ? ...não toh vendo RLOCK() nenhum....
Realmente, o que o colega alaminojunior disse faz sentido, vc deve testar dbappend()

Eu uso uma função para isso: Outra coisa é o final, eu uso ao contrario ou seja primeiro dou o dbcommit() e depois libero o registro()

não toh vendo RLOCK() nenhum....

Meu amigo gauchinho, o que se supõe com isso ?

Travar5("PREN") não quer dizer que seja um RLOCK() pode ser apenas um FLOCK(), sei lah ele deveria ter postado essa função tmb.

Travar5("PREN") não quer dizer que seja um RLOCK() pode ser apenas um FLOCK()

Que diferença faz ?

Ah esse chimarrão !!!

alaminojunior escreveu:

Travar5("PREN") não quer dizer que seja um RLOCK() pode ser apenas um FLOCK()

Que diferença faz ?

Ah esse chimarrão !!!

Se for mult-usuario ? o RLOCK() vai travar o arquivo todo, empedindo outros Dbappend()

Travar o arquivo todo é função do FLock(). O RLock() trava apenas o registro apontado.

Ops, Enverti...