[firebase-br] Queda servidor firebird

Kelver Merlotti kmerlotti em gmail.com
Sex Out 16 14:37:11 -03 2015


Pessoal, não estou acompanhando a fundo a discussão (sorry), mas só pra
contribuir com meus 2 centavos: é TOTALMENTE possível usar os controles
Data-aware sem qualquer ligação com o banco de dados, usando ClientDataSet,
por exemplo, ou o FDMemTable, do FireDAC. Conecta, pega os dados e trabalha
em memória, desfrutando de tudo que o framework lhe oferece para
manipulação de dados!
Respeito quem prefere trabalhar sem DataControls, mas cuidado ao afirmar
que esse é o melhor caminho =)
Abraços e bom final de semana,

*Kelver Merlotti*
Coordenador Editorial da Active Delphi
Twitter: http://www.twitter.com/kmerlotti

2015-10-16 10:30 GMT-03:00 Gladiston Santana <gladiston em vidy.com.br>:

> Bem, a maneira que se dá o uso do TDataset cria essas complicações que
> requerem conciliar os links dos Dataset com os componentes ligados a ele
> quando ocorre a quebra de conexão.
> Há uma nova abordagem do XE usando LiveBindings em componentes comuns
> linkando-os com TFields/TDataset.
> É possivel com o uso de LiveBinds, por exemplo, assinalar um StringGrid com
> os dados de um TDataset dando a impressão de um DBGrid, Edit/Checkbox com
> TFields causando a impressão de um DBEdit/DBCheckbox.
> Se a conexão quebrar, quebra o TFields/TDataset é claro, mas o LiveBinds só
> dependeu deles no momento da captura da informações, depois disso seus
> componentes vão manter o mesmo 'Status Quo' mesmo que a conexão seja
> finalizada. Dá uma observada nos videos do Youttube sobre apresentações do
> Embarcadero no Brasil e você verá melhor.
> Eu recomendo a qualquer um que use uma conexão separada quando submeter as
> alterações (insert/update/delete), pois nela você cria uma
> função/classe/procedure unica para todas as suas queries que pode testar se
> a conexão esta aberta ou fechada e nesse caso abre-a e a manterá assim
> mesmo após o sucesso ou falha da query.
> Quando eu digo abrir/fechar é porque minhas conexões são estabelecidas em
> cada formulário, daí se o formulário fechar, o form é destruído e a conexão
> também.
> Claro que dá para tudo isso fazer passar por uma unica conexão única no
> form principal ou datamodule e parece sábio fazer assim, mas conexões
> distintas para cada contexto me dá a versatilidade de lidar com isolamentos
> diferentes, um formulário de venda de passagens, por exemplo, teria um tipo
> de transação pessimista e não deixaria outro chegar perto do acento
> enquanto aquele preenchimento não fosse resolvido, por outro lado,
> informações pouco relevantes poderiam ser editados simultamente e
> sobreviveria a mais recente, ainda noutro relatório usaria um isolamento
> que vê tudo no modo dirty, até o que ainda não foi confirmado com commit.
>
> Se fosse uma linguagem para web como php você não poderia ter uma conexão
> permanente, no máximo uma conexão dinamica (pconnect) onde a conexão abre e
> fecha sozinho conforme o fluxo de dados chegam ou saem. No delphi poderia
> ser assim também, mas a borland/inprise/embarcadero quiseram facilitar e na
> minha opinião se saíram bem, mas cria esses embrolhos de como conciliar
> dados depois de uma queda de conexão. Nessas situações, isto é, em
> latencias muito altas e qualidade ruim de rede, o ideal é usar DataSnap.
>
> inte+
>
> Em 16 de outubro de 2015 09:27, <firebase em dominioinf.com.br> escreveu:
>
> > Bom dia Gladiston,
> >
> > Também não uso Datawares em meu sistema. Isso ja é muito bom. Mas a minha
> > preocupação é que
> > como o banco de dados é bem grande, as vezes leva em torno de 5 segundos
> > para conectar, e
> > liberar para uso.
> >
> > Então imagina o cliente abrindo e fechando a tela de vendas, e a cada vez
> > que abrir e fechar
> > demorar até 5 segundos ou mais para abrir o banco de dados.
> >
> > Acho eu que não seria a melhor solução. Diferente de por exemplo,
> > programar em php, que
> > a conexão parece ser super rapida com MYSQL, nem se percebe que toda vez
> > que enviamos um
> > novo registro ele abre o banco de dados e no final fecha.
> >
> > Dai alguem pode perguntar, então porque não usa o mysql? Ja fiz esse
> > teste, com o zeos e
> > a conexão também fica demorada, não é privilégio somente do firebird.
> >
> > Mas voltando ao assunto principal, o interessante seria a conexão
> > conseguir se recuperar de onde
> > parou quando for perdida e dar continuidade na operação. Não sei se isso
> é
> > possivel mas continuo
> > na luta para chegar nesse estagio.
> >
> > Grato
> >
> > Rodrigo
> >
> >
> ______________________________________________
> 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://www.firebase.com.br/pesquisa_lista.html
>



Mais detalhes sobre a lista de discussão lista