Quick update: Re: Failure to save as postgresql database

[Jack]

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