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?

GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=796698. Please continue processing the bug there and please update any external references or bookmarks.