Hi,
Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote on 2006-06-10:
> 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
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
tags 370502 - moreinfo
tags 370502 + confirmed,upstream
thanks
Thomas Themel <[EMAIL PROTECTED]> writes:
> I've made up a simple test data set that seems to reproduce the issue
> just fine since I didn't like the idea of circulating my accounting data
> for the last two years too widely.
Of co
--- Begin Message ---
Hi,
Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote on 2006-06-06:
> I don't use QIF, so I don't have any QIF files to work with.
I've made up a simple test data set that seems to reproduce the issue
just fine since I didn't like the idea of circulating my accounting data
for t
Thomas Themel <[EMAIL PROTECTED]> writes:
> I just noticed that the new gnucash version seems to corrupt imported
> data sets. I use the package with [EMAIL PROTECTED] set, and the
> following procedure reproducably loses a lot of transactions from my
> accounts:
Hi, thanks for your bug report.
Package: gnucash
Version: 1.9.6-3
Severity: critical
Justification: causes serious data loss
Hi,
I just noticed that the new gnucash version seems to corrupt imported
data sets. I use the package with [EMAIL PROTECTED] set, and the
following procedure reproducably loses a lot of transactions from
6 matches
Mail list logo
