More analysis: Failure to save as postgresql database

[Jack]

The first few errors I thought were the problem were all "downstream"  
failures caused by a db transaction/commitUnit having become invalid  
due to a previous query failure and not calling finish on the query.

I'm now pretty sure the first actual failure happens when writeFile  
calls writeOnlineJobs. which calls clearTable on kmmSepaOrders.  The  
select on that table fails, because that table is not present in the  
database.  It appears that all other tables, except that one and  
kmmNationalAccountNumber are correctly created.  Just to confirm that,  
if I manually create those two tables (any definition - they are  
recreated before being used) then I can successfully save to the  
database.

Looking at only the first of those two tables, kmmSepaOrders is created  
in setupSepaOnlineTransfer (after being dropped if it exists.)  That  
routine is called in setupStoragePlugin, which in turn is called in   
actOnOnlineJobInSQL, which also calls  
actOnSepaOnlineTransferObjectInSQL.  actOnOnlineJobInSQL is called in  
addOnlineJob, which is called in writeOnlineJobs.  (There are some  
other calls of these functions, but I've stuck to those it looks like  
should get the table created.)    What I don't really follow, is that  
in writeOnlineJobs, kmmSepaOrders is cleared before being dropped and  
recreated, and clearing it required selecting and then deleting from it.

What I don't understand, is why those two tables are not created when  
all the other tables are initially created.  I have not yet tracked  
that down.  I wonder if it is because those tables are only necessary  
under certain circumstances.  However, I'm not sure why (or even if) I  
am the first person to get caught by this situation.

Separately, I realized that the bug  
(https://bugs.kde.org/show_bug.cgi?id=430163) that led me to this issue  
is about something else, and not this particular error.  I'm wondering  
if I should create a bug or an issue for this problem.  An issue might  
be appropriate if we also want to address adding more checks for other  
query functions failing, and not currently getting caught.

Jack