This is the schema of the splits and transactions tables:

CREATE TABLE `splits` (
  `guid` varchar(32) NOT NULL,
  `tx_guid` varchar(32) NOT NULL,
  `account_guid` varchar(32) NOT NULL,
  `memo` varchar(2048) CHARACTER SET utf8 NOT NULL,
  `action` varchar(2048) CHARACTER SET utf8 NOT NULL,
  `reconcile_state` varchar(1) CHARACTER SET utf8 NOT NULL,
  `reconcile_date` timestamp NULL DEFAULT '0000-00-00 00:00:00',
  `value_num` bigint(20) NOT NULL,
  `value_denom` bigint(20) NOT NULL,
  `quantity_num` bigint(20) NOT NULL,
  `quantity_denom` bigint(20) NOT NULL,
  `lot_guid` varchar(32) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;


CREATE TABLE `transactions` (
  `guid` varchar(32) NOT NULL,
  `currency_guid` varchar(32) NOT NULL,
  `num` varchar(2048) CHARACTER SET utf8 NOT NULL,
  `post_date` datetime DEFAULT '1970-01-01 00:00:00',
  `enter_date` datetime DEFAULT '1970-01-01 00:00:00',
  `description` varchar(2048) CHARACTER SET utf8 DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Well, there's no indication of an error from the DB in the tracefile, so what exactly went wrong?

As an aside, I see that I missed converting the reconcile-date field timestamp->datetime.

John, this bug was created as a follow up to an IRC conversation yesterday:
https://lists.gnucash.org/logs/2018/06/27.html#T14:20:31

There is some more background there. The short summary: new transactions can be created but existing transactions can't be altered - at least the account name can't be modified. Changing an account name seems to work ok until you close an reopen gnucash.

Geert,

Ah, thanks. Yes, that sheds a bit more light.

Jan, try running this query from the mysql console after making a backup:

ALTER TABLE splits MODIFY COLUMN reconcile_date DATETIME DEFAULT '1970-01-01 00:00:00';

John, i change the column type, but unfortunately the transaction's account still resets to the "adjustment account" (i don't know the correct english term for "Ausgleichskonto").
From what i can see it only affects transactions which were added somewhen after the MariaDB upgrade, but doesn't affect records that get added right now. I just pulled a couple of new ones from my online banking, and changing those works as expected. Still doesn't work for those old ones, though.

It doesn't actually matter what Ausgleichskonto is in English, it's just a name. 

Changing the reconcile_date column type to DATETIME rules out the possibility that passing 1970-01-01 00:00:00 is the problem; DATETIME's legal range is 1000-01-01 00:00:01 to 9999-12-31 23:59:59.

Run the following queries in mysql console:
select guid, name from accounts where guid='dbbfdf44d89b731dd04235a70ed00136';
select guid, name from accounts where name='Ausgleichskonto';
UPDATE splits SET guid='db3a92379a414d069ce6c47897ac5f62',tx_guid='e027f7ce1f874723ac82655b633a25e5',account_guid='a67e6cd4678a88893546c26b8172262e',memo='',action='',reconcile_state='n',reconcile_date='1970-01-01 00:00:00',value_num=120000,value_denom=100,quantity_num=120000,quantity_denom=100 WHERE guid = 'db3a92379a414d069ce6c47897ac5f62';

select guid, account_guid from splits where guid='db3a92379a414d069ce6c47897ac5f62';

and report the output.

Here's the output (that split isn't related to the account, though? i noticed when i saw the account's name and the split's value):

MariaDB [gnucash]> select guid, name from accounts where guid='dbbfdf44d89b731dd04235a70ed00136';
+----------------------------------+--------+
| guid                             | name   |
+----------------------------------+--------+
| dbbfdf44d89b731dd04235a70ed00136 | Gehalt |
+----------------------------------+--------+
1 row in set (0.00 sec)

MariaDB [gnucash]> select guid, name from accounts where name='Ausgleichskonto-EUR';
+----------------------------------+---------------------+
| guid                             | name                |
+----------------------------------+---------------------+
| 3926ef86ccf04984cab4132056a56b7e | Ausgleichskonto-EUR |
+----------------------------------+---------------------+
1 row in set (0.00 sec)


MariaDB [gnucash]> UPDATE splits SET guid='db3a92379a414d069ce6c47897ac5f62',tx_guid='e027f7ce1f874723ac82655b633a25e5',account_guid='a67e6cd4678a88893546c26b8172262e',memo='',action='',reconcile_state='n',reconcile_date='1970-01-01 00:00:00',value_num=120000,value_denom=100,quantity_num=120000,quantity_denom=100 WHERE guid = 'db3a92379a414d069ce6c47897ac5f62';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0

MariaDB [gnucash]> select guid, account_guid from splits where guid='db3a92379a414d069ce6c47897ac5f62';
Empty set (0.00 sec)

That update query was copied and pasted from your tracefile, so the problem is that the split you're trying to update doesn't exist in the database.

The other split in the tracefile is  'bf7feb39f69647cfb96f7fc0408e8fc5'. Does it exist?

Did you delete and recreate the transactions as a work around to not being able to change them?

No, that one doesn't exist either. I didn't delete or recreate any transactions, only tried to edit change the book (i think that's the correct term?) and did a couple of sync against my online banking.

Then the problem isn't with MariaDB, the problem is that GnuCash is using the wrong GUID for the split.

What register "view" are you using when you change the account, basic or split?

If you create a new book and save it to the MariaDB server does the problem persist? What if you save it to SQLite3?

I've been using the "basic" view pretty much exclusively.
I didn't try creating a new book and saving it there, but you mentioning the wrong GUID got me thinking, so i duplicated some transactions and deleted the original ones, and the duplicates could be saved to their respective books just fine.

Does that mean that you can change the accounts on the duplicates?

Still confused by the terms, but "i can do with the duplicates what i couldn't do with the original ones", e.g. change a transactions book(?) in the account(?) that syncs with my online banking from the fallback book(?) "Ausgleichskonto-EUR" to the one it's supposed to be booked to, like "rent" or "salary". ;-)

Now I think I don't understand at all what you're doing. I had thought that you were opening a register and changing the transfer account (Herkunftskonto (Haben)) and that it changes in the UI but reverts to the previous value when you reload the database.

For reference, your "book" is what a database holds, so it could be considered equivalent. 

Ah, I looked up Ausgliechskonto in de.po, it's Imbalances. I guess that it's important to know that after all. 

So you're doing an AQBanking import. Are you dismissing the import matcher and changing the transactions in the bank account register?

Since you've apparently lost interest I'm closing this as incomplete. If you want to continue resolving the problem just reopen the bug and answer the question about AQBanking.