I've investigated my transaction/split issue further and it appears as though the problem is in how qof determines that the books are dirty.
There is an alt_dirty_mode flag in qof and the gc engine sets it to TRUE. When this flag is set, *after* the backend is called during the second part of a qof_commit_edit() call, the collection and book are marked dirty. While this may be fine for an XML backend where the commit does not really save anything and therefore the books really *are* dirty, it is not OK for an SQL backend. If the concept of the books being dirty means that there is unsaved content, then the backend should have more control over that status. Derek's vision seems to be that sqlite replaces xml as the standard backend, and that xml might still exist as an import/export mechanism. If that is what is adopted (seems fine to me, but some concensus would be good), then I'll need to look at and possible clean up the whole dirty mechanism. For now, I think I've fixed my problem by pushing the problem code down into the xml backend and out of qof. This means that a commit using the file backend *does* mark the books as dirty, whereas a commit using the sql backend does not. Phil _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
