Autor
Mensagem
Postado em: 16/5/2012 09:23:55 PM
ai galera, boa noite!
tenho 3 tabelas com a seguinte estrutura:
tbl compra, tbl venda e tbl caixa.
as tabelas compra e venda possui os campos;
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
as tabelas compra e venda ao serem preechidas em seus registros alimentam automaticamente a tabela caixa
a qual faz o papel de fluxo de caixa.
até ai tudo bem como faço quando editar uma das tabelas origem a tabela destino (caixa) altere tambem o registro
sem criar uma nova linha?.
Delphi7 - bd access
tenho 3 tabelas com a seguinte estrutura:
tbl compra, tbl venda e tbl caixa.
as tabelas compra e venda possui os campos;
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
as tabelas compra e venda ao serem preechidas em seus registros alimentam automaticamente a tabela caixa
a qual faz o papel de fluxo de caixa.
até ai tudo bem como faço quando editar uma das tabelas origem a tabela destino (caixa) altere tambem o registro
sem criar uma nova linha?.
Delphi7 - bd access
Postado em: 16/5/2012 10:03:39 PM
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?
Seria isso?
Postado em: 18/5/2012 01:17:46 AM
Citação:
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?
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.
Postado em: 18/5/2012 07:48:59 AM
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
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
Postado em: 18/5/2012 06:21:58 PM
Puxa vida Marcos! em primeiro lugar obrigado por ressponder, então o que devo fazer para contornar estes problemas?
Postado em: 19/5/2012 10:00:15 AM
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.
Postado em: 19/5/2012 10:04:31 AM
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.
Postado em: 21/5/2012 07:39:21 AM
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 ???
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 ???
Postado em: 21/5/2012 02:51:04 PM
Citação:
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 ???
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.
Postado em: 21/5/2012 06:21:47 PM
Citação:
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.
Citação:
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 ???
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
Postado em: 23/5/2012 12:27:55 AM
Citação:
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
Citação:
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.
Citação:
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 ???
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!
