This cropped up while doing some tests... Start Gnucash with --nofile, take all default options and when saving use sqlite3 option and appropriate file name, close Gnucash. Start Gnucash again with --nofile, again take all default options and when saving use sqlite3 again with the same file name, dialogue appears asking if you want to overwrite, say yes and then this dialogue appears.. "The server URL at /root/unstable-sql3-1.gnucash experienced an error or encountered bad or corrupt data", close In the trace file entries like these are present... * 13:30:11 CRIT <gnc.engine.sx> gnc_sx_get_sxes_referencing_account: assertion 'sxactions != NULL' failed * 13:30:21 WARN <gnc.backend.dbi> [GncDbiBackend<Type>::session_begin()] Might clobber, no force * 13:30:24 CRIT <gnc.backend.dbi> [error_handler()] DBI error: 1: table versions already exists * 13:30:24 CRIT <gnc.backend.dbi> [GncDbiSqlConnection::create_table()] Error in dbi_result_free() result * 13:30:24 CRIT <gnc.backend.dbi> [error_handler()] DBI error: 19: UNIQUE constraint failed: versions.table_name * 13:30:24 CRIT <gnc.backend.dbi> [GncDbiSqlConnection::execute_nonselect_statement()] Error executing SQL INSERT INTO versions VALUES('Gnucash',2070000) * 13:30:24 CRIT <gnc.backend.sql> [GncSqlBackend::execute_nonselect_statement()] SQL error: INSERT INTO versions VALUES('Gnucash',2070000) * 13:30:24 CRIT <gnc.backend.sql> [GncSqlBackend::set_table_version()] SQL error: INSERT INTO versions VALUES('Gnucash',2070000) * 13:30:24 CRIT <gnc.backend.dbi> [error_handler()] DBI error: 19: UNIQUE constraint failed: versions.table_name * 13:30:24 CRIT <gnc.backend.dbi> [GncDbiSqlConnection::execute_nonselect_statement()] Error executing SQL INSERT INTO versions VALUES('Gnucash-Resave',19920)
For testing another issue I tried to overwrite an existing gnucash mysql book and ran into similar errors. So this likely affects all db backends.
I have just pushed a fix for this issue. It will appear in gnucash 3.3. It's a quasi dupe of bug 792724 in that the same logic error was there for both database types. However the logic error happened in different code paths for both db types so I'm treating them differently.
