jeronimoza

Contribuindo um pouco mais com esta discussão... Enfrentei algumas outras "inconsistências"(inconformidades do meu projeto) com as "auto" transações do FireDAC. Foi necessário alterar o valor default da propriedade "TxOptions.StopOptions", ficando "[xoIfAutoStarted, xoFinishRetaining]". Dentre algumas inconformidades, surgiram alguns "deadlocks", transações que ficavam abertas devido a muitas tabelas estarem abertas em tempo de desenvolvimento. Leitura que contribuiu para elucidação: https://stackoverflow.com/questions/36696159/firedac-applyupdates-and-transaction-control

Sim, já havia olhado a referida documentação. Como dito ali, este seria o melhor caminho... porém, não é viável aplicar este conceito a minha necessidade. Estou migrando do BDE para FireDac(7 para Tokyo), e isto implicaria em, primeiramente, setar o "Connection" de todos os componentes de acesso a dados para conseguir centralizar este controle. No momento, estou trabalhando com com a conexão definida ao "ConnectionName". Entendo que o grande ponto no meu contexto é: o FireDac abre uma transação implícita ao dar um ".Post" que, se não for comitada, só será no momento no encerramento da conexão.

Bom dia. Para contribuir com a postagem, segundo a documentação disponível em http://docwiki.embarcadero.com/Libraries/Tokyo/en/FireDAC.Stan.Option.TFDTxOptions.AutoCommit, não há a necessidade de setar a flag AutoCommit ao startar uma transação. Para contribuir com a discussão, enfrentei o mesmo problema. Depurando, identifiquei que a Flag AutoCommit só tem efeito sobre as instruções aplicadas através de "ExecSQL"; ao dar um "Post" em um FDTable a flag não dá commit no banco, deixando isto para quando a conexão for encerrada(dará o commit pois está definido nas configurações da conexão - TxOptions.DisconnectAction). Contornei isto, dando um "CommitRetaining" a cada "Post" da FDTable. Como estou migrando do BDE para FireDac, criei uma "casca" que foi aonde pude aplicar esta ideia a todos os "Posts" dados pelo sistema.