It looks like the bug is caused by having a QIF file being imported which does not contain valid UTF8 data. Then when it's written out, what gets written out is invalid, and so when it's written in, it can't be parsed and the transactions vanish.
The correct solution is to ask the user what the charset is on the data being imported, since the QIF format simply doesn't say. This is, it turns out, a pervasive problem in the various importers in gnucash, so extra thanks for finding this bug and reporting it! The correct solution will not likely be implemented in time for gnucash 2.0. What is planned for gnucash 2.0 is to validate the imported data. Exactly what that will look like (what happens when the imported data is not valid UTF8) is uncertain at this point. When that intermediate goal is reached, this bug will get a lower severity to indicate that it no longer causes data loss. (If what happens when invalid UTF8 is loaded is to simply reject the data and refuse to load, this will become an important bug; if what happens is that the loading takes place with some alteration of characters or whatnot, it will become a normal bug.) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
