I think I've figured out the root cause of 666329 [1]. There are three components: * The autosave timer can fire while the user is in the middle of an edit (meaning that the objects in memory may not be in a clean state suitable for being saved). * The SQL backend is set up to check for, and disallow saving of, tuples where one or more fields is NULL. In the case at hand, it's a taxtable entry with no account guid. * The SQL backend takes a meat-axe approach to "synching", dropping all of the tables in the database, re-creating them, and saving all of the objects in memory to the new tables.
I see several fixes here. The quickest is to replace gnc_dbi_sync_all() with gnc_dbi_safe_save() as what's called by be->sync. That will at least prevent data loss. Also, I think that the autosave function should be moved out of gnome-utils into backend/xml, since it isn't really appropriate for the SQL backends which are supposed to save everything as part of a commitEdit. However, it's bad to be doing a save when the user is in the middle of an edit for any backend, so there should also be an edit lock to prevent the save if anything has an open edit. The autosave should fire when the edit is committed or aborted. That's going to take rather more extensive architectural changes. I propose that we should hold off releasing 2.4.9 until I can do the first two (i.e., save_save and moving autosave). As an aside the user says that he doesn't see the problem on 2.4.7, but I can't see any commits between 2.4.7 and 2.4.8 that would have anything to do with this. Does anyone else? Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
