On 2021.01.24 16:57, Jack wrote:
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
First, I see that if a commitUnit is ended, it is popped off the stack,
but the actual "commit" call is only made if the stack is empty. That
means my concern above may not be valid, but I still don't understand
the purpose of having nested commitUnits.
Looking at the output full of debug statements, the query prior to the
error is "SELECT count(*) FROM kmmNationalAccountNumber", called from
writeOnlineJobs(). That function calls clearTable, which does a query,
but silently succeeds even if the select fails. I added an else to the
if, with a MYMONEYEXCEPTIONSQL, and now the failure is from "SELECT
count(*) FROM kmmSepaOrders" because "Query error No 0: ERROR:
relation "kmmsepaorders" does not exist."
Just to be sure there wasn't something funny or leftover from previous
use, I dropped the kmm database, recreated it, confirmed it was empty,
tried again, and got the same error. So, the underlying problem is
that KMM creates a new Postgresql database without some required
tables. I don't know if this is a database version issue, or might be
related to my cmake settings.
Separately, I suppose we should do more testing for failed sql
functions, as such failures can be so hard to actually track down.
