Please try the following:
* Start GnuCash from the command line as follows: gnucash --log gnc.backend.dbi=debug
* Do an import
* Quit GnuCash
* Find the tracefile (https://wiki.gnucash.org/wiki/Tracefile) and attach it to this bug report. It will include your transactions descriptions and amounts so you may want to edit it to obfuscate the activity if you think it sensitive, but please leave any strings containing characters not used in English.

<Mechtilde sent the trace file to me privately.>

The problem appears to be  "DBI error: 1292: Incorrect datetime value: '1970-01-01 00:00:00' for column `gnucash`.`splits`.`reconcile_date` at row 1" which occurs 4 times. You start with a "save as" creating a new database and it's clear that the tables are created with DATETIME; that should be unimportant for MariaDB since https://mariadb.com/kb/en/library/date-and-time-literals/ says that TIMESTAMP fields are treated as DATETIME unlike MySQL. 

https://mariadb.com/kb/en/library/datetime/ is pretty clear that 1970-01-01 00:00:00 should be a legitimate value, so it would seem to be a bug in MariaDB.

Hello,

how can I work around it?

do I have to change to XML back? Then I can't do evaluation with OpenOffice/Libreoffice.

Mechtilde

I looked deeper what happens at 2019-01-31. this was the day I did an update frm version 3.3 to 3.4.

I didn't update mariadb some days before. the first transactions of the 2019-01-31 are correct. the later ons failed.

So I guess there is a change in GnuCash which triggers this problem.

Would using SQLite3 be a suitable workaround? It's not picky about timestamps.

You might also try saving-as to XML and then saving-as back to MySQL.

I did the TIMESPEC to DATETIME changes in August, so they'd have been in 3.3. I don't see commits after that that would affect this.

Can you open your database with mysql and do `describe splits;` and make sure that the reconcile_splits field is type datetime?

I opened the database with mysql and did `describe splits;`
Here is the result:

MariaDB [gnucash]> describe splits;
+-----------------+---------------+------+-----+---------------------+-------+
| Field           | Type          | Null | Key | Default             | Extra |
+-----------------+---------------+------+-----+---------------------+-------+
| guid            | varchar(32)   | NO   | PRI | NULL                |       |
| tx_guid         | varchar(32)   | NO   | MUL | NULL                |       |
| account_guid    | varchar(32)   | NO   | MUL | NULL                |       |
| memo            | varchar(2048) | NO   |     | NULL                |       |
| action          | varchar(2048) | NO   |     | NULL                |       |
| reconcile_state | varchar(1)    | NO   |     | NULL                |       |
| reconcile_date  | timestamp     | YES  |     | 0000-00-00 00:00:00 |       |
| value_num       | bigint(20)    | NO   |     | NULL                |       |
| value_denom     | bigint(20)    | NO   |     | NULL                |       |
| quantity_num    | bigint(20)    | NO   |     | NULL                |       |
| quantity_denom  | bigint(20)    | NO   |     | NULL                |       |
| lot_guid        | varchar(32)   | YES  |     | NULL                |       |
+-----------------+---------------+------+-----+---------------------+-------+
12 rows in set (0.010 sec)

And there's the problem. 
In the mysql shell do
ALTER TABLE splits MODIFY COLUMN reconcile_date datetime;

John thanks. now I have 

MariaDB [gnucash]> describe splits;
+-----------------+---------------+------+-----+---------+-------+
| Field           | Type          | Null | Key | Default | Extra |
+-----------------+---------------+------+-----+---------+-------+
| guid            | varchar(32)   | NO   | PRI | NULL    |       |
| tx_guid         | varchar(32)   | NO   | MUL | NULL    |       |
| account_guid    | varchar(32)   | NO   | MUL | NULL    |       |
| memo            | varchar(2048) | NO   |     | NULL    |       |
| action          | varchar(2048) | NO   |     | NULL    |       |
| reconcile_state | varchar(1)    | NO   |     | NULL    |       |
| reconcile_date  | datetime      | YES  |     | NULL    |       |
| value_num       | bigint(20)    | NO   |     | NULL    |       |
| value_denom     | bigint(20)    | NO   |     | NULL    |       |
| quantity_num    | bigint(20)    | NO   |     | NULL    |       |
| quantity_denom  | bigint(20)    | NO   |     | NULL    |       |
| lot_guid        | varchar(32)   | YES  |     | NULL    |       |
+-----------------+---------------+------+-----+---------+-------+
12 rows in set (0.006 sec)

Then I tried again to modify the old (wrong) entries. That doesn't work.

It works now for new entries. So I imported the entries again from bank account and deleted the wrong one.

What did you try to modify? Reassigning the account from Imbalance-EUR to the correct income/expense account?

Did you get the same "Unable to save transaction" error?

Are you still in the same session so that you can find the database error in gnucash.trace and post it?

I tried to reassigning the account from Imbalance-EUR to the correct income/expense account. 

I didn't see any error message. But I found /tmp/gnucash.trace

* 19:28:08  WARN <gnc.app-utils>            8 (apply-smob/1 #<catch-closure 558055e718e0>)
In c-interface.scm:
     22:4  7 (gnc:call-with-error-handling _ _)
In ice-9/boot-9.scm:
    829:9  6 (catch #t #<procedure 5580561997b0 at c-interface.scm:23:8 ()> # …)
In c-interface.scm:
    29:29  5 (_)
In unknown file:
           4 (eval-string ";;; -*-scheme-*-\n\n;; Sample system-wide config…" …)
In ice-9/boot-9.scm:
   2312:4  3 (save-module-excursion #<procedure 5580561caac0 at ice-9/eval-s…>)
In ice-9/eval-string.scm:
     38:6  2 (read-and-eval #<input: string 558056382a80> #:lang _)
In ice-9/eval.scm:
   223:20  1 (proc #<directory (gnucash utilities) 558055ffbb40>)
In unknown file:
           0 (%resolve-variable (7 . #) #<directory (gnucash utilities) 5580…>)

Unbound variable: /home/mechtilde/.gnucash/german-taxinvoice.scm
* 19:28:26  WARN <qof> [gnc_numeric_to_decimal()] GncNumeric 1600/40 could not be represented as a decimal without rounding.
* 19:29:15  WARN <qof> [gnc_numeric_to_decimal()] GncNumeric 1600/40 could not be represented as a decimal without rounding.
* 19:34:32  WARN <qof> [gnc_numeric_to_decimal()] GncNumeric 1600/40 could not be represented as a decimal without rounding.
* 19:34:45  WARN <qof> [gnc_numeric_to_decimal()] GncNumeric 1600/40 could not be represented as a decimal without rounding.

So what happened with the transaction?

New transactions work fine now.

I cant reassign the old ones. The corrections are not stored.

Are there errors in the trace log saying why not?

I posted the trace at 2019-04-20 13:44:37 EDT (comment 10). I didn't havve any further information, sorry.

Sorry, I didn't realize that that was the whole file. Very strange that it's refusing to save but not raising a DBError warning. Anything in the MySQL logs?

There is also no entry in the error.og when I reassign the entries. Soory.

As John mentioned in IRC I did gnucash --logto=stderr --log gnc.backend.dbi=debug and get:

* 18:26:04 DEBUG <gnc.backend.dbi>     [GncDbiSqlConnection::begin_transaction] BEGIN
* 18:26:04 DEBUG <gnc.backend.dbi>     [GncDbiSqlConnection::execute_nonselect_statement] SQL: UPDATE splits SET guid='10f80439e4a2417c8ce52c433f2fadfc',tx_guid='c925e82c760242108042fc30aff0d32c',account_guid='8c48b4719808b41a0ddadef5c428b01d',memo='',action='',reconcile_state='n',reconcile_date='1970-01-01 00:00:00',value_num=25956,value_denom=100,quantity_num=25956,quantity_denom=100 WHERE guid = '10f80439e4a2417c8ce52c433f2fadfc'
* 18:26:04 DEBUG <gnc.backend.dbi>     [GncDbiSqlConnection::execute_select_statement] SQL: SELECT * FROM slots WHERE obj_guid='10f80439e4a2417c8ce52c433f2fadfc' and slot_type in ('9', '8') and not guid_val is null
* 18:26:04 DEBUG <gnc.backend.dbi>     [GncDbiSqlConnection::execute_nonselect_statement] SQL: DELETE FROM slots WHERE obj_guid = '10f80439e4a2417c8ce52c433f2fadfc'
* 18:26:04 DEBUG <gnc.backend.dbi>     [GncDbiSqlConnection::commit_transaction] COMMIT
* 18:26:04  WARN <qof>     [gnc_numeric_to_decimal()] GncNumeric 1600/40 could not be represented as a decimal without rounding.

The IRC conversation is at https://code.gnucash.org/logs/2019/04/23.html#T11:45:42

The net result is that the update query above works but the split is deleted and a new unbalanced split is created when the database is reloaded.