[firebase-br] Dados excluídos automaticamente

[Everton Patricio Pereira]

É verdade, a melhor ferramenta é aquela que se sabe usar. Observar
estatísticas do servidor certamente é importante, e por vezes, até
fundamental para um bom dba. No que diz respeito às triggers, realmente sua
utilização em demasia é prejudicial, assim como tudo em excesso. Como você
mesmo disse, deixa o código "macarrônico". No entanto, procuro manter meia
visão da sobre o assunto, pois assim como há a visão de manter toda a
lógica do sistema no bd, para tornar fácil a troca da aplicação por parte
da linguagem de programação, há também a visão de manter toda a lógica do
sistema na aplicação, a fim de tornar fácil também a troca do banco de
dados, por exigência do cliente ou qualquer outro motivo.
Realmente, como você comentou, não só na programação, mas em todos os
aspectos da vida como um todo é necessário sermos humildes e aceitarmos que
não sabemos de tudo, que não somos perfeitos. Alíás, o único ser perfeito é
Deus, e por esse motivo, o que nos faz diferentes e, por conseguinte, o que
faz nossos sistemas diferentes, é a nossa busca constante pelo
aperfeiçoamento.

Obrigado.

Em 30 de agosto de 2012 10:44, Gladiston Santana
<gladiston em vidy.com.br>escreveu:

> Quando se utiliza uma suite de acesso a dados, seja dbx, zeos, ibo e tantas
> outras devemos entender como elas funcionam, para mim, todas as principio
> são ruins até conhece-las bem.
> Por isso incentivei a observar a estatística do servidor, por exemplo, se
> as AIT e OIT estiverem muito distantes significa que você está mantendo
> transações e talvez não soubesse disso, exatamente porque acha que a suite
> tem cuidado disso muito bem. Outros programas sofisticados também funcionam
> bem, como o Carlos sugeriu, contudo observar as estatísticas do banco não
> deve fazer nenhum mal e tem resultado imediato.
>
> Eu uso triggers desde os primordios do SQL Server enquanto ainda era Sybase
> e exatamente por conhecer tão bem, só as utilizo em casos especiais,
> pois quando se tem muitas triggers o DB fica "macarronico" e dificil de
> diagnosticar falhas. Além disso, vocÊ tem que se lembrar que se usar a
> linha de comando para realizar insert/update/delete para consertar
> um possível erro lógico, tem que desliga-las primeiro. Por isso uso tão
> pouco triggers, na realidade uso apenas para guardar valores antigos ou
> auditagem, pois elas funcionam como dedo-duro até mesmo para minhas
> manutenções.
>
> Eu prefiro as procedures, mesmo quando programo em multi-camadas porque
> elas fornecem a logica completa do inicio ao fim. Não dependem de suites
> funcionais usadas no seu programa, posso mudar de .exe para o formato web
> que não terei de transportar logicas extensas para um php/asp, tenho nivlel
> de permissao de usuário ou role sem me preocupar com permissao de tabela,
> já ficam compiladas no servidor... enfim quase não vejo como não
> utilizá-las. É como diz o ditado : "Porque o galo fecha o olho quando canta
> ? R: Porque já conhece a musica de cor.", o mesmo se aplica a mim. Já estou
> tão familiarizado com programação no lado do servidor que soa natural essa
> abordagem.
>
> []'s
>
> Em 30 de agosto de 2012 10:14, Everton Patricio Pereira <
> evertonkiai em gmail.com> escreveu:
>
> > Carlos, obrigado pela sua contribuição. Irei utilizar o FBScanner para a
> > análise.
> >
> > Gladiston, agradeço também pela sua ajuda. No que diz respeito às
> > transações, eu as controlo e finalizo em cada insert/update/delete, não
> as
> > deixando, assim, muito tempo abertas. No meu caso, creio que não preciso
> > colocar um commit ao finalizar a aplicação como um todo pois já faço isso
> > para cada mudança no banco de dados (se compararmos com o caso do outro
> > colega).
> > Quando utilizo apenas um SQLDataSet, eu faço o controle transacional
> > explicitamente, como mostra o modelo:
> >
> >    Transacao.TransactionID := 1;
> >    Transacao.IsolationLevel := xilREADCOMMITTED;
> >    SQLDataSet.StartTransaction(Transacao);
> >
> >    try
> >     SQLDataSet.ExecSQL;
> >     SQLConnection.Commit(Transacao);
> >    except
> >     on E : Exception do
> >      begin
> >       SQLDataSet.Rollback(Transacao);
> >       ShowMessage('Ocorreram erros.'+#13+E.Message);
> >      end
> >    end;
> >
> > No entanto, quando o conjunto de SQLDataSet, DataSetProvider e
> > ClientDataSet, utilizo apenas o ApplyUpdates no ClientDataSet. Creio que
> > esse método já chama o commit automaticamente.
> >
> > No entanto, vi em um forum um camarada utilizando de forma explicita o
> > commit em conjunto com o ApplyUpdates, como segue o modelo:
> >
> >     TD.TransactionID := 1;
> >     TD.IsolationLevel := xilREADCOMMITTED;
> >     dm.SQLConnection1.StartTransaction(TD);
> >     try
> >      dm.cdsClientes.ApplyUpdates(0);
> >      dm.SQLConnection1.Commit(TD);
> >     except
> >      dm.SQLConnection1.Rollback(TD);
> >     end;
> >
> > Creio que seja desnecessário, se sevarmos em conta que o ApplyUpdates já
> > chama o Commit automaticamente. Mas ao seu ver, isso está correto? Pode
> > gerar algum erro?
> >
> > Notei também que você prefere não utilizar as triggers. Ao meu ver, elas
> > facilitam o trabalho, pois executam ações conforme as mudanças nas
> tabelas
> > acontecem, como você já sabe. Eu utilizo as triggers para lançamento de
> > comissões, lançamento de valores no caixa e controle de estoque. Você
> > conhece uma forma mais interessante de realizar essas ações fora a parte
> os
> > triggers, principalmente no que diz respeito ao controle de estoque?
> >
> > Obrigado a todos pela atenção.
> >
> >
> >
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>