[firebase-br] Queda servidor firebird

[Carlos Wilson]

Depois que eu vi um mini curso do Guinter Pauli da ClubeDelphi sobre o 
uso do ClientDataSet só uso ele agora, tenho apenas uma conexão no dm 
principal e funciona muito bem com os componentes dbWare. Pra que ficar 
reiventando a roda? Sei que o LiveBindings funciona com a VCL, mas foi 
um artificio inventado principalmente para o firemonkey pois no 
firemonkey não existe dbware. Mas o liveBindings por si só não resolve o 
problema da ligação dos TFields com o Connection. Mas a arquitetura 
baseada no ClientDataSet se não resolver em 100% dos casos mas em 90% é 
certeza.

[]'s
Carlos Wilson
Formosystem
Informática e Automação Comercial

Em 16-10-2015 14:37, Kelver Merlotti escreveu:
> 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
>>
> ______________________________________________
> 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
>