Found it: Re: Failure to save as postgresql database

[Jack]

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.