Editar tabela origem e tabela destino

Bom , se fosse um banco maior, eu diria pra usar Triggers, mas como se trata do access... você pode usar o próprio evento AfterPost de um dataset ligado à tabela origem. SE o estado for de edição, altere o registro, SE for inserção, adicione um novo na tabela caixa.
Seria isso?

Sim eu uso o evento afterpost para inserir os dados na tbl origem e se refletem na tbl destino via os campos relacionados, até ai tudo bem, o que eu não to conseguindo arrumar é uma forma de quando eu editar um registro na tbl origem o valor seja automaticamente alterado na tbl destino sem inserir uma nova linha quando der o post, não sei se dá pra entender é por ai.

O grande prolema neste tipo de arquitetura para mim é que ele é passivel de erros
Vc tem que controlar estas alteraçõs em um bloco atômico , ou seje se edita em uma edita na outra
O problema é garantir isto de modo RAD do Delphi . NA nova versão do Delphi isto até é possivel pois o
controle transação foi todo restruturado.

Olhando para sua estrutura a

tabelas compra
codcompra|datcompra|descricao_compra|$unitcompra|qtdecompra|desccompra|totcompra
tbl venda:
codvenda|datvenda|descricao_venda|$unitvenda|qtdevenda|descvenda|totvenda
tbl caixa:
codigo|data|historico|entradas|saidas|soma

A tabela Compra e Venda (com exceção dos nomes ) é muito semelelhante a tabela Venda
Ou seja poderia ser Normalizada e vc ter uma tabela só que fissesse os dois pápeis
Também nçao necessitaria ter uma taela Fluxo de caixa , ela poderia ser obtida utilizando
um campo Virtual ... Como segue este exemplo

http://marcosalles.wordpress.com/2012/05/07/classe-para-gerar-o-fluxo-de-caixa-em-delphi-parte-ii/

Quero destacar tb que não estou resolvendo diretamente sua necessidade , somente é minha opinião pessoal
Imagine vc ter uma quantidade considerável de registro(RecNo=10000) , uma edição na tabela Venda (RecNo=200) acarretará
enormes alterações na Tabela caixa . Pior ainda , este campo é fisico , esta alteração precisa ser aplicada , consome
recursos de banco e ainda mais é passivel de erros . A meu ver é Bad Smell

Puxa vida Marcos! em primeiro lugar obrigado por ressponder, então o que devo fazer para contornar estes problemas?

Ola, um problema que poderia ocorrer é a falta de integridade dos dados, por exe: quando voce gravar venda tem que gravar em caixa, e quando gravar em compra tem que gravar no caixa, pois pode ocorrer de gravar em venda e acabar a energia ou cair a rede e nao gravar em caixa, voce tera seu caixa desatualizado. uma solução é colocar a conexão em transação e só comitar quando gravar os dois, ou não comita nada.

Outra coisa, não sei se existe a necessidade da tabela caixa, pois acredito que seria a soma da tabela venda menos a soma da tabela de compras, e como o Marco falou acima, voce pode utilizar apenas uma tabela incluindo apenas um campo para indicar se foi uma operação de compra ou venda.

Normalizando sua Base de Dados ... Pq três tabelas se uma so faz a via das três ????

Como foi mostrado no artigo , vc controla o fluxo de caixa com um campo Virtual

O que vc não esta entendendo ou não esta concordando com este raciocíneo ???

Ok Marcos vou tentar fazer com uma tabela só usando um campo virtual tipo saldo? e depois na hora de fazer os relatorios tem como fazer via sql? desculpe ainda sou new bie nessa área.

Vc pode utilizar sql para fazer os relatórios , mas tb pode utilizar o proprio fied .. È como se fosse um Field qualquer

Ta certo que no exemplo que lhe passei criei em RumTime este Field , mas nada impede que vc crie este Field em nivel de projeto ..Ai é so liga-lo ao seu relatorio

Certo vou recomeçar tudo e fazer os testes de pois volto aqui de nôvo pra dizer como ficou, até mais!