Fórum Porque não deleta meu registro, usando 3 camadas? #315531
09/03/2006
0
segue minhas especificações:
Mestre:
Options: [poCascadeDeletes,poPropogateChanges,poAllowCommandText,poUseQuoteChar]
Filho: [poCascadeDeletes,poCascadeUpdates,poPropogateChanges,poAllowCommandText,poUseQuoteChar]
ResolveToDataSet := True
Todos os UpdateModes estão como [b:b232f2f0ce]upWhereKeyOnly[/b:b232f2f0ce]
O que pode ser que está acontecendo?
P.S.: No banco está como CASCADE no FK..
Titanius
Curtir tópico
+ 0Posts
09/03/2006
Emerson Nascimento
ao invés de Mestre/Detalhe, prefira NestedDatasets.
Gostei + 0
09/03/2006
Martins
[b:867b8c12a8]Emerson.en[/b:867b8c12a8] vc poderia explanar mais sobre o assunto ou nos fornecer um exemplo?
Obrigado.
Gostei + 0
09/03/2006
Titanius
Vixi.. como eu comito? pois uso CDS, como eu comito la no servidor? e o que vem a ser NestedDatasets? :shock:
[]s
Gostei + 0
09/03/2006
Eselvati
Vixe, q assunto cabeludo!!
Ja estou a anos tentando resolver estes problemas e outros mais, mas sem chance, na hora q começo a desenvolver um aplicativo 3 camadas, a hora q chego la na frente, esbarro nos mesmos problemas de tentativas anteriores....
ex: Transações controladas pelo aplicativo cliente (a arquitetura vai querer te empurrar q as transações tem q ser controladas pelo aplicativo servidor e q vc tem q criar metodos no servidor para isto ou o midas faz tudo sozinho), visto q em uma aplicação client/server o controle da transação (starttransaction/commit/rollback) fica a nosso cargo e funciona muito bem.
Master detail so com NESTEDDATASET, é uma junção de 2 ou mais componentes sqlquery/sqldataset parecida com o masterdetail q conhecemos no Client/Server, a unica coisa q achei interessante nesta arquitetura foi isso (NESTEDDATASET).
veja este artigo:
http://www.firebase.com.br/fb/artigo.php?id=299
São estes e outros problemas q me estao me desanimando com esta arquitetura, ainda estou apostando no Client/Server.
Ederson
Gostei + 0
09/03/2006
Emerson Nascimento
isso não é totalmente verdadeiro. no caso citado (mestre/detalhe) a transação pode ser controlada totalmente pelo aplicativo cliente. na verdade essa ´transação´ sempre será controlada pelo aplicativo cliente.
transações controladas no aplicativo servidor seriam transações com várias tarefas. por exemplo:
a - geração de notas fiscais
- manipula o estoque
- gera o contas a receber/pagar (em função da nota fiscal ser de saída/entrada)
- gera as informações contábeis
- atualiza os valores das contas bancárias
- etc
- marca a nota como processada
b - estorno de pagamento
- estorna as informações contábeis
- estorna os valores das contas bancárias
- exclui as informações de cheques (se for o caso)
- etc
- reabilita o título para cobrança
esses exemplos devem ser feitos por métodos no servidor, visto que cada um deles é um procedimento fechado: ou faz tudo, ou não faz nada. sem contar que é muito mais rápido sendo processado no servidor, bastando para isso enviar os campos chave e tendo como retorno uma mensagem (ou um booleano) indicando se tudo correu bem ou não.
estou montando um texto sobre NestedDatasets. assim que estiver pronto eu vou publicá-lo nesse tópico, a pedido do nosso colega Martins.
Gostei + 0
10/03/2006
Eselvati
NF->Baixa Estoque->Gera livros Fiscais->Gera Contas a Receber
vou envolver no minimo umas 10 tabelas na transação e entao vou ter q ter o controle da transação em minhas mãos, sem q os nesteddataset da operação commitem ou desfaçam a transação por conta propria
ex:
metodonoservidor.starttransaction
if nesteddatasetdanota.applyupdates(0) then begin
if metodonoservidor.baixaestoque(clientdatasetdeprodutosdanota) then begin
if funcaoparagerarlivrosfiscais then begin; //no aplicativo cliente dentro dela vai ter um applyupdates(0)
if funcaoparagerarcontasareceber then begin// no aplicativo cliente pois deve-se resolver valor de parcelas/vencimentos...etc
metodonoservidor.commit;
else
metodonoservidor.rollback;
else
metodonoservidor.rollback;
.........
seria mais ou menos uma logica assim?
Ederson Selvati
Gostei + 0
10/03/2006
Emerson Nascimento
seria mais ou menos assim:
no programa cliente:
clientdatasetdanota.applyupdates(0);
no módulo servidor:
você implementa o evento BeforeUpdateRecord do provider da nota fiscal para que ele...
- baixe o estoque
- gere as informações fiscais
- gere o financeiro (a pagar ou receber, conforme o caso)
todos os procedimentos do evento BeforeUpdateRecord ficam no contexto da transação aberta pelo applyupdates. se ocorrer qualquer erro, todos eles serão cancelados. você pode ainda optar por gravar a nota fiscal mesmo que haja erro nos demais procedimentos, para que possa ser feita uma nova tentativa posteriormente. o modo fica a seu critério.
uma das maiores facilidades desse tipo de desenvolvimento é o fato de toda a regra de negócio ficar num único local.
imagine o meu caso:
eu trabalho numa empresa que possui 16 filiais (algumas em são paulo - inclusive a matriz, outras na bahia, outras no rio grande do sul e em outros estados, com o setor operacional trabalhando 24h). o banco de dados fica centralizado na matriz, onde o sistema pode ter mais de 350 usuários simultâneos.
agora imagine que uma regra importante foi alterada -> ao emitir a nota fiscal, além de:
- baixar o estoque
- gerar as informações fiscais e
- gerar o financeiro (a pagar ou receber, conforme o caso)
agora eu preciso, obrigatoriamente:
- se for nota de saida, gerar o contas a pagar para a transportadora com o valor do frete cobrado
- enviar um email para o cliente/fornecedor informando:
. a) se nota de saida, a data da emissao da nota e a previsão de chegada da mercadoria
. b) se nota de entrada, a data de recebimento da nota e a data de pagamento da mesma
- gerar um log das operações
imagine que isso tem que começar a funcionar a partir de hoje (10/03/2006).
- se essa regra estiver no aplicativo cliente, eu preciso que os usuários atualizem o sistema. estou na mão deles. se eles não atualizarem:
. a) o cliente/fornecedor ficará insatisfeito - pois não receberá o email informativo
. b) o contas a pagar poderá ficar incorreto, pois a informação de pagamento para a transportadora não estará lançado e
. c) o log não será criado
tornando as informações inconsistentes com a nova regra, além de gerar um tremendo mal estar junto à gerência/diretoria da empresa.
- se essa regra estiver no aplicativo servidor, ninguém precisará atualizar o sistema. quando a nota fôr emitida, toda a nova informação será gerada de acordo com o solicitado, de forma transparente ao usuário.
estou totalmente adaptado ao desenvolvimento em camadas utilizando COM+ via sockets. não consigo mais me imaginar desenvolvendo sistemas de outra forma. além disso, a velocidade é fantástica, podendo ser usado facilmente em conexões via linha discada.
Gostei + 0
10/03/2006
Titanius
vc desenvolveu um scktsrvr.exe ou usou do proprio delphi? Qual versao do delphi, voce usa?
[]s
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)