[firebase-br] RES: RES: RES: RES: RES: Dúvida com TIB_Query x TIBODataset (Performance)

Qua Jan 26 14:53:12 -03 2011

é importante que entre:
 Result:= Contar.fieldByName('COUNT').AsInteger;
 If Assigned(Contar) then FreeAndNil(Contar);

tenha:

contar.close;
contar.unprepare;

Assim, a query será fechada e despreparada no servidor. Se a query
ficar "por alguma razão" preparada, a transação PODE ficar aberta.

mas à grosso modo é isto. Apenas verifique os métodos da SESSIONPROPS
(existe muita mágica feita por este cara além de mudar a cor dos
edits)

veja mais detalhes nas mensagens antigas (um bom ponto de partida é
este aqui: http://mail.firebase.com.br/pipermail/lista_firebase.com.br/2008-April/051202.html)

==========================
Eduardo Jedliczka
Apucarana - Pr
==========================

Em 25 de janeiro de 2011 16:18, José Otávio Lussari
<tavinhol em gmail.com> escreveu:
> Ok Eduardo, obrigado pela explicação : )
> Agora, vamos la: Vc disse que o IB_Query tem uma aba transaction! Vc quis
> dizer o IB_Connection, não foi?
> Eu criei uma função que efetua esse count e retorna o numero de registros da
> SQL "Count"...
>
> function Conta_Registro(SQL_Count: String): Integer;
> var Contar: TIB_Query;
> begin
>   Contar:= nil;
>   Contar:= TIB_Query.Create(Contar);
>   Contar.IB_Connection:= DMGeral.IB_Connection;
>
>   with Contar do begin
>      Close;
>      SQL.Clear;
>      SQL.Add(SQL_Count);
>      Open;
>   end;
>
>   Result:= Contar.fieldByName('COUNT').AsInteger;
>   If Assigned(Contar) then FreeAndNil(Contar);
> end;
>
> Até então, eu não estava colocando um TIB_Transaction como vc vê no codigo
> acima!
> Seguindo a lógica acima, como eu trabalharia com transação nesse código?
> eu iria "startar" ela em qual momento? Transação Read Only tem que ser
> finalizada com COMMIT, ROLLBACK?
>
> Veja que eu tbem tenho uma função para criar transações:
>
> function TDMGeral.CriarTransacao(Owner: TComponent): TIB_Transaction;
> var
>   ib_Transacao: TIB_Transaction;
> begin
>   ib_Transacao:= TIB_Transaction.Create(Owner);
>   ib_Transacao.IB_Connection:= IB_Connection;
>   Result:= ib_Transacao;
> end;
>
> Desculpe a chuva de perguntas amigo, mas vc tocou em um ponto fraco meu
> "ainda"... Transações...
>
> atenciosamente,
>
> [ ]’s
> José Otávio Lussari
> Analista de Sistemas
> Bacharel em Sistemas de Informação
>
>
> -----Mensagem original-----
> De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em
> nome de Eduardo Jedliczka
> Enviada em: terça-feira, 25 de janeiro de 2011 16:02
> Para: FireBase
> Assunto: Re: [firebase-br] RES: RES: RES: RES: Dúvida com TIB_Query x
> TIBODataset (Performance)
>
> Transações... kkk... agora você fez uma boa pergunta.
>
> Quando falamos de qualquer componente de acesso, sempre há duas formas
> de se trabalhar com transações: explicitas ou implicitas.
>
> As implicitas geralmente são (ou deveriam ser) controladas
> automaticamente pelos componentes de acesso. O problema é que a
> maioria dos componentes, abre uma transação ad-eternum (ou seja, só
> fecha quando termina o aplicativo) e isto gera vários problemas de
> performance.
>
> As explicitas são controladas pelo próprio desenvolvedor.
>
> Isto também vale para o IBO, só que ele tem alguns recursos extras,
> por exemplo, se você não setar um transaction para uma query, o IBO
> irá criar uma nova transação especialmente para aquela query (veja que
> o IB_QUERY tem uma aba transaction).
>
> Assim, pode-se desenvolver um sistema grande usando quase que
> totalmente transações automáticas. A excessão fica para aquelas
> operações que realmente exigem um controle, como por exemplo uma
> tranferência de carteira, o lançamento contábil que não seja da 1ª
> forma, uma baixa de múltiplas duplicatas, etc.
>
> Mas é preciso alterar (via código) algumas propriedades, para que as
> transações automáticas realmente sejam fechadas (este código já foi
> postado várias vezes aqui na lista).
>
> Quanto ao isolation, também depende muito da rotina. Mas geralmente
> (telas de cadastros simples, por exemplo) eu uso auto-commit,
> read-commited, wait transaction.
>
> lembre-se diferente de outros bancos, no firebird, um SELECT EXIGE uma
> transação ativa.
>
> ==========================
> Eduardo Jedliczka
> Apucarana - Pr
> ==========================
>
>
>
>
> Em 25 de janeiro de 2011 14:52, José Otávio Lussari
> <tavinhol em gmail.com> escreveu:
>> Ok Eduardo, mas me fale uma coisa por gentileza: Vc diz estar em uma
>> transação separada da transação da query em questão!
>> Entao eu teria um outro TIB_Transaction ligado nessa query com a opção
>> ReadOnly marcada, é isso?
>> e em Isolation, o que eu deixaria marcado?
>> Vc colocou uma outra duvida pra mim: Uma IB_Query que eu uso apenas para
>> Select's precisa ter um TIB_Transaction?
>> Desculpe amigo, como eu disse sou novato em IBO...
>>
>> atenciosamente,
>>
>> [ ]’s
>> José Otávio Lussari
>> Analista de Sistemas
>> Bacharel em Sistemas de Informação
>>
>>
>> -----Mensagem original-----
>> De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br]
> Em
>> nome de Eduardo Jedliczka
>> Enviada em: terça-feira, 25 de janeiro de 2011 14:36
>> Para: FireBase
>> Assunto: Re: [firebase-br] RES: RES: RES: Dúvida com TIB_Query x
> TIBODataset
>> (Performance)
>>
>> Sem sombra de dúvidas, esta proposição é muito melhor do que o
>> FetchAll, mas há um grande inconveniente:
>>
>> - São duas operações de busca no banco de dados. E isto pode gerar um
>> pequeno overheat no banco de dados (se a tabela for grande ou se o
>> select tiver muitos joins);
>>
>> Para isto, seria interessante que a Query que traz o count estivesse
>> numa transação separada (read-only) e pudesse ser executa após o OPEN
>> do grid.
>>
>> Se você ainda deseja exibir numeros reais e absolutos, este método
>> parece ser melhor, mas se você contenta-se em mostrar um "tem mais do
>> que X", a solução apresentada pelo magno também é boa.
>>
>> abraço,
>>
>> ==========================
>> Eduardo Jedliczka
>> Apucarana - Pr
>> ==========================
>>
>> Em 25 de janeiro de 2011 11:11, José Otávio Lussari
>> <tavinhol em gmail.com> escreveu:
>>> Certo Eduardo! Entendi perfeitamente sua lógica!
>>> Mas vc acha que ao montar uma SQL de consulta conforme os critérios do
>>> usuário, eu montar juntamente uma SQL "Count", eu estaria perfendo
>>> performance?
>>> Pois um SELECT COUNT me retorna apenas um numero! Vc não acha que seria
>> mais
>>> vantajoso fazer algo do tipo:
>>>
>>> var x: Integer;
>>>
>>> SQL_Usuario: SELECT CAMPO1, CAMPO2 FROM TABELA WHERE CAMPO2 LIKE
>>> 'Parafuso%';
>>>
>>> SQL_Count: SELECT COUNT(*) FROM TABELA WHERE CAMPO2 LIKE 'Parafuso%';
>>>
>>> x:= SQL_Count;
>>>
>>> if x >300 then
>>>  label.caption := 'retornou mais de 300 registros'
>>> else
>>>  label.caption := inttostr(x) + ' registros';
>>>
>>> O você acha?
>>>
>>> atenciosamente,
>>>
>>> [ ]’s
>>> José Otávio Lussari
>>> Analista de Sistemas
>>> Bacharel em Sistemas de Informação
>>>
>>> -----Mensagem original-----
>>> De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br]
>> Em
>>> nome de Eduardo Jedliczka
>>> Enviada em: terça-feira, 25 de janeiro de 2011 11:00
>>> Para: FireBase
>>> Assunto: Re: [firebase-br] RES: RES: Dúvida com TIB_Query x TIBODataset
>>> (Performance)
>>>
>>> Na época eu não usava o IBO, então usava o RowNum mesmo.
>>>
>>> Mas dá para fazer (logo após o open da procura) uma espécie (ok, eu
>>> sei que há uma função específica para isto, mas faz algum tempo que
>>> nem tenho windows na minha máquina, quem dirá delphi).
>>>
>>> x := 0;
>>>
>>> while (x <= 300) and not qy.eof() do
>>>  begin
>>>    qy.next;
>>>    inc(x);
>>>  end;
>>>
>>> if x >300 then
>>>  label.caption := 'retornou mais de 300 registros'
>>> else
>>>  label.caption := inttostr(x) + ' registros';
>>>
>>> ==========================
>>> Eduardo Jedliczka
>>> Apucarana - Pr
>>> ==========================
>>>
>>> Em 25 de janeiro de 2011 08:52, José Otávio Lussari
>>> <tavinhol em gmail.com> escreveu:
>>>> Gostei dessa sua idéia... mas pra vc saber que tinha mais do 300 fotos,
>> vc
>>>> implementou oq?
>>>> Já pensei em colocar em minhas telas de consultas um Select first 300...
>>> mas
>>>> fazendo assim, ele nunca irá trazer mais do que 300 e não saberei se os
>>>> parâmetros que o usuário passou realmente retornaria mais de 300...
>> certo?
>>>>
>>>> Penso nesses detalhes pelo seguinte: Desenvolvi um projeto de memória de
>>>> calculo aqui na empresa e quando liberei o sistema para produção, eu
>>>> acompanhei o usuário por um determinado tempo. Minhas telas de consultas
>>> era
>>>> liberadas, não tinha bloqueio! Eu deixei as opções de consultar por
>> alguns
>>>> campos chaves e com as opções: Iniciados com, que contenham e Seja
> igual.
>>>>
>>>> Certo dia voltei acompanhar o usuário para explicar uma nova atualização
>> e
>>>> para minha surpresa ele estava fazendo o seguinte: Escolheu um campo que
>>>> tinha em comum com todos os produtos e digitava uma letra em comum com
>>> todos
>>>> os registros, que no caso era o "W", ou seja, ele sempre trazia todos os
>>>> registros da tabela e depois ficava procurando um a um na Grid... não me
>>>> pergunte porque ele fazia isso, pois jamais eu entenderei isso... rsrsrs
>>>>
>>>> Agora, estou com outro projeto em IBX e como ele vai crescer, comecei
>>> migrar
>>>> para IBO. Como eu sei que vai acontecer isso novamente, quero encontrar
>>>> alguma forma de obrigar o usuário filtrar mais as consultas... nesse
>>> projeto
>>>> que mencionei acima, eu coloquei vários bloqueios nas consultas, entre
>>> elas
>>>> um intervalo de no Maximo 3 meses entre datas e trazer apenas os 30
>>>> primeiros registros... fechei mesmo!!!
>>>> Agora nesse projeto que estou migrando, estou estuando a melhor forma
>>>> possível de lidar com isso e por isso que estou recorrendo a vocês..
>>>> entendeu?
>>>> obrigado pelas dicas amigo!
>>>>
>>>> atenciosamente,
>>>>
>>>> [ ]’s
>>>> José Otávio Lussari
>>>> Analista de Sistemas
>>>> Bacharel em Sistemas de Informaçã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
>
>
> ______________________________________________
> 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
>