[firebase-br] Queda servidor firebird

[Gladiston Santana]

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