On 2021.01.23 01:31, Thomas Baumgart wrote:
On Samstag, 23. Januar 2021 02:00:46 CET Jack wrote:
[snip....]
The actual current error is "Query error No 0: ERROR: current
transaction is aborted, commands ignored until end of transaction
block" so I'm now digging into tracking if there is a previous SQL
call which is failing, but not triggering an explicit end to that
transaction.
I think that is where KMMSqlQuery can help. I had to add a bunch of
calls to QSqlQuery::finish() to solve this/a similar problem when
reusing a query object.
I agree that there is probably a missing call to QSqlQuery::finish()
but I haven't yet figured out where.
What I've been trying to do is to add debug statements to track all the
SQL transactions (commitUnits) and have found something I think might
(or might not) be contributing to the issue. The code appears to nest
commitUnits. (They never get deeper than 3.) My current guess is
that this is not intentional, but I have still not wrapped my head
around the whole SQL handling.
The problem is that Postgresql (I have not checked explicitly for
sqlite or MySql) does NOT have real nested transactions. I THINK (but
am still not sure) that this means a COMMIT or ROLLBACK of an inner
transaction will actually have that action on the outermost transaction.
So, for now, I'm trying to get a good representation of the flow of
commitUnits and queries.
Jack
