[firebase-br] Dados excluídos automaticamente

[Gladiston Santana]

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.
>
>
>