On 2021.01.25 19:54, Jack wrote:
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
Doing the same thin in MariaDB (not yet sure about MySQL) it actually
segfaults. In this case, the "Select count(*) from kmmSepaOrders"
fails, and he QT_DEBUG_SQL qDebug output includes d->sqlresult->size()
which is not valid for a failed query, and segfaults. (It also
segfaults without the QT_DEBUG_SQL, but I don't have a version compiled
that way I can run under gdb to confirm.)
Is it possible that not creating kmmSepaOrders and
kmmNationalAccountNumber is just an oversight because they are
relatively recent additions to the program at all?
