Pessoal,
Fazendo uns testes com o LETOdb, tudo funcionando perfeitamente... ate que resolvi incluir TRANSAÇÕES no codigo. Ja tinha visto em outro poste algo a respeito de 'perca do ponteiro' nas transações com Leto, mas isso foi em 2010... pensei que hj ja estaria consertado.
No inicio percebi algumas coisas estranhas... tipo gravação de apenas parte dos dados no mesmo dbf, mas mudei a ordem de gravação nos dbf's e parece ter resolvido essa parte. Depois de todos os ajustes feito, tudo gravando sem erros... eis que surge uma coisa maluca aqui no sistema e passei horas analisando o codigo sem perceber nada de errado. LEMBRANDO QUE USO ESSE MESMÍSSIMO CODIGO HA ANOS COM DBFCDX e TAMBÉM COM MEDIATOR+MYSQL e nunca havia dado problema nenhum.
Não sei relatar direito qual seria o bug, mas parece perca do ponteiro mesmo! Isso se usar transações! Pq usando o leto, mas sem transação, o codigo tbm funciona q eh uma maravilha!
Peguei 02 produtos e realizei varias movimentações no estoque. Para os 02 produtos usei a mesma ordem de lançamentos.
Vejamos a imagem abaixo para lançamento SEM TRANSAÇÃO:
Produto 12
Ordem Lançamento Movimento
94536 - 08.06
94537 - 08.06
94538 - 08.06
94539 - 01.06
94540 - 02.06
Percebam no relatorio na coluna SALDO, como este evolui CORRETAMENTE pela ordem de data que foi lançado! Tinha zero, entrou 3, saldo 3. Depois tinha 3, entrou 10, saldo 13... e assim vai.
Agora vejam na imagem abaixo um outro produto, lançado na mesma sequecia de movimentos e datas, mas COM TRANSAÇÕES:
Produto 14
Ordem Lançamento Movimento
94541 - 08.06
94542 - 08.06
94543 - 08.06
94544 - 01.06
94545 - 02.06
Nesse caso, com o mesmíssimo codigo e com o USO DE TRANSAÇÕES, a evolução do SALDO endoidou! Saldo anterior aparece 6 (o correto seria ZERO); Tinha 19, entrou 2, saldo 11 (??? endoidou)
Negocio estranho e até dificil de relatar para os caras russos consertarem!