On 2021.01.01 13:57, Jack wrote:
On 2020.12.31 19:02, Jack wrote:
In looking at https://bugs.kde.org/show_bug.cgi?id=430163 I got both
mariadb and postgresql set up. I can save to mariadb (mysql) but
not to postgresql. The error I get is:
-----
Cannot save to current database: Error in function void
MyMoneyStorageSqlPrivate::deleteKeyValuePairs(const QString&, const
QVariantList&) : deleting kvp for STORAGE
Driver = QPSQL, Host = localhost, User = jack, Database = kmm
Driver Error:
Database Error No -1:
Text:
Error type 0
Executed: DELETE FROM kmmKeyValuePairs WHERE kvpType = ? AND kvpId =
?;
Query error No 42601: ERROR: syntax error at or near "("
LINE 1: EXECUTE ('STORAGE', '')
^
(42601) QPSQL: Unable to create query
Error type 2
/var/tmp/portage/app-office/kmymoney-5.1.9999/work/kmymoney-5.1.9999/kmymoney/plugins/sql/mymoneystoragesql_p.h:1927
-----
In that call, kvpType is "STORAGE" and idList contains one empty
string. I have no idea where the question marks in the "Executed"
line come from. I see no obvious errors in the qSql code, other
than perhaps wondering if the "" is getting correctly bound to
:kvpID but I know I'm grabbing at straws here.
My other question is where LINE 1: EXECUTE('STORAGE','') comes
from. Those would be the proper two values for the single execution
of the DELETE statement, but that seems to have come from much
deeper in the libraries, although I don't know if it's still within
QSql orin actual Postgresql code.
Any suggestions on how to further troubleshoot will be appreciated,
although I know my next effort will be to run under gdb.
With a hint from TonyB, I'm beginning to think there might be a
problem within QSql and its Postgres innards. The syntax error in
"EXECUTE ('STORAGE', '')" appears to be the lack of a name for the
prepared statement. I'll have to track down how it creates the
actual psql PREPARE statement from the query.prepare call.
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.
