2.3.15/tax package: basic questions

[J. Alex Aycinena]

On Fri, Aug 20, 2010 at 12:41 PM, Phil Longstaff <plongstaff at rogers.com> wrote:
> This actually makes sense.  I'm sure I know what the problem is.  With the
> XML backend, when you write, everything (transaction data, prices, tax code
> assignments, etc.) is written to the file.  When you Save As to a new
> sqlite3 file, everything is written.  The difference is in what happens when
> you modify something.  For transaction data and prices, there is a special
> step to commit the changes.  With XML backend, this commit step does nothing
> (because everything will be written to the XML file when you save), but with
> the sqlite3 backend, this commit step saves the changes to the sqlite3
> file.  There is no commit step for tax code assignments.  With XML backend,
> this is fine, because they will be saved when the file is written.  For
> sqlite3, this is a problem because there is no clue that something needs to
> be written.
>
> We ran into this previously with some of the business preferences which are
> stored in the same basic way that tax code assignments are.  These
> preferences weren't being saved until I added a commit step for them.  We
> also need to add this commit step for tax code assignments and everything
> else which is currently stored in the kvp-frame for the book.  I'll need to
> search the code to see what else might have the same problem.
>
> Phil
> ---------

Well, thanks to Jannick we caught that problem because i certainly
hadn't. I have also added tax-entity-type as a book-level KVP that
would need to be saved too if it isn't now.

Alex