Delphi DBX TSQLConnection RunTime e Firebird 2.5

29/09/2016

0

Amigos, estou convertendo um sistema para Firebird 2.5 Super Classic que foi criado em Delphi 7 para Delphi XE

O componente de acesso é DBExpress e a maior mudança foi adequar a nova forma de trabalho das transações BeginTransaction(TDBXIsolations.ReadCommitted), CommitFreeAndNil(T);

A maior parte do processamento é realizado pelo banco por SP ( Stored Procedures )

Estranhamente verifiquei travamentos nessas SP, mesmo no aplicativo estando sendo explicitamente iniciado e finalizado uma transação

Quando eu usava os componentes IBX , fazia meu StartTransaction e Commit e não havia esse problema.

Já meio que em desespero, deixei de usar a conexão do SqlConnection do DataModule, configurado

commitretain=False
waitonlocks=True
isolationlevel=ReadCommitted


e passei a criar em RunTime as Conexões, e a executar ( já era criado em RunTime um TSQLStoredProc ) da mesma forma a SP e destruir a conexão e isso liberava as SP

Um DBA que conversei ( especialista em Oracle ) disse que no Oracle não se deve manter conexões aberta por muito tempo e essa é a maneira correta.

Um colega que trabalha com Delphi disse que terei inúmeros problemas ao fazer as ações fora da conexão principal.

Nos exemplos que vejo na internet vejo as aplicações por um SQLConnection criam uma conexao e tudo trafega dentro do contexto dessa conexão.

Percebi que a velocidade aumentou em muito, entretanto ainda não consegui fazer um teste com carga elevada e antes de colocar em produção resolvi perguntar aos especialistas do uso diário.

Obrigado.
Antonio Carlos

Antonio Carlos

Responder

Posts

29/09/2016

Hélio Devmedia

Olá Antonio Carlos,

Se você migrou do IBX para o DBExpress provavelmente agora você está utilizando o ClientDataSet e provider.

Utilizando componentes DBExpress, você não precisa abrir transações e finalizar sempre como faria nos componentes IBX,

Isso porque SQLConnection, abre uma conexão com o banco, recupera os Dados através de um SQLTable, SQLDataSet ou SQLQuery e o provider encapsula estes dados e envia ao ClientDataSet.

O ClientDataSet, manipula tudo em memória, sem precisar abrir uma transação, e no final de vários edits, inserts, posts e deletes, você executa o comando ApplyUpdate(-1) do ClientDataSet e ele envia as alterações para o DataSetProvider que se encarrega de abrir uma transação com o Banco, executar os comandos SQLs e finalizar a transação, devolvendo erros em caso de algum...

Você só precisa usar beginTransaction e EndTransaction, quando depender de realizar várias operações simultâneas À aquela que seria realizada com o ClientDataSet.

A menos que você esteja montando os SQLs na unha e não esteja utilizando o ClientDataSet, recomendo fazer o curso de ClientDataSet que existe aqui na DevMedia, que envolve inclusive o tema do ReconcileError que é a forma como o DBExpress controla alterações do mesmo registro em máqunias diferentes ao mesmo tempo.

segue alguns links úteis:

https://www.devmedia.com.br/curso-de-dbexpress-e-datasnap-parte-iii/1186
https://www.devmedia.com.br/curso/trabalhando-com-clientdataset/108
https://www.devmedia.com.br/dbexpress-4-artigo-revista-clube-delphi-129/20895

Qualquer coisa pode me chamar novamente.
Caso este tópico tenha sido útil, por favor, marque com um joinha para eu saber que pude ser útil.
Responder

29/09/2016

Antonio Carlos

A pergunta faz menção a StoreProcedure nada se relaciona a ClientDataSet. Mas já que acha que dar ApplyUpdate faz Comitt fique certo que Não. A prática demostra que isso nem sempre ocorre. Eu sempre antes de dar um Post eu início a transação e o dependendo do resultado do ApplyUpdate faço Commit ou Rollback. Inclusive se colocar um.monitor no banco de dados vai perceber mais claramente isso.
Responder

Assista grátis a nossa aula inaugural

Assitir aula

Saiba por que programar é uma questão de
sobrevivência e como aprender sem riscos

Assistir agora

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar