After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794982 - Business data gets garbled when carrying a SQL file from V 2.6.19 to V 3.0
Business data gets garbled when carrying a SQL file from V 2.6.19 to V 3.0
Status: RESOLVED DUPLICATE of bug 794936
Product: GnuCash
Classification: Other
Component: Business
3.0
Other Mac OS
: Normal normal
: future
Assigned To: gnucash-core-maint
gnucash-core-maint
Depends on:
Blocks:
 
 
Reported: 2018-04-04 16:59 UTC by Jo Wetzig
Modified: 2018-06-30 00:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jo Wetzig 2018-04-04 16:59:35 UTC
Carried SQLITE data file to V 3.0 from 2.6.19. File had some stub bills and customers that I played around with previously.
A bill came up as due (correctly), which V 2.6.19 and previous version had ignored.
Looking at the details I find a discount rate of 70.367.355.177.108 percent and a credit of 10.052.479.311.015 + 3/7 (the 3/7 worries me ;) - I always extend plenty of credit to customers...)
These values do crop up also in some other test bills.
In addition the number of items and the single item prices had been upped.

I checked a backup of the file with V 2.6.19: the discount was set at 0 percent as was the credit. It appears that somehow the values were garbled upon carrying from V 2.6.19 to V 3.0.

Hardware is a Macbook, Mac OS X Sierra (10.12.6).
Gnucash V 3.0 vanilla, except: environment file modified as per [Bug 794933] and custom Tax scm file entries added for German income tax.

Cheers from the other side of the pond.

Joachim
Comment 1 Frank H. Ellenberger 2018-04-04 18:10:08 UTC
A strange discount was already reported in Bug 794932 - Invoice report throws with numerical-overflow.
Comment 2 Adrien 2018-04-05 06:22:23 UTC
It's not just discounts: https://bugzilla.gnome.org/show_bug.cgi?id=794936

And it's not just moving from 2.6.19 to 3.0. I moved a 2.6.19 XML file with no issues to 3.0. On using 3.0 to save as sqlite and then re-opening, I get the same exact wrong quantities, prices and discounts. (the discounts as noted all seem to be unique)
Comment 3 John Ralls 2018-04-05 14:07:05 UTC
Please open your SQLite3 file with sqlite3 and do the following query:
  SELECT guid, i_price_num, i_price_denom, i_discount_num, i_discount_denom FROM entries;

Are the values sane?
Comment 4 Jo Wetzig 2018-04-06 12:11:01 UTC
>Please open your SQLite3 file with sqlite3 and do the following query:
>  SELECT guid, i_price_num, i_price_denom, i_discount_num, i_discount_denom
>FROM entries;

Not all of them ;(((

"a091a44e7259b2b2fba207e14be6f2ea" "2000000"  "1000000"	"0"	   "1"
"4da6ba68f004f65ce22ae2f4f738bb22" "30000000" "1000000"	"20000000" "1000000"
"9d42cb293dc1952bdb99446ed708c0c8" "30000000" "1000000"	"20000000" "1000000"
"8a5029c38e8255ef275c02063a87f5ea" "1000000"  "1000000"	"0"	   "1"
"7d5225ed198029c094e8a69f86f1eee2" "30000000" "1000000" "20000000" "1000000"
"5ec50f6e6dc459952e2e04b01b9c27cd" "30000000" "1000000" "20000000" "1000000"
"301c90831e1af9e65bdaca358dbad40a" "30000000" "1000000"	"0"        "1"
"fafd8b9b573e40b5224122eb1cc816e0" "30000000" "1000000"	"20000000" "1000000"
"5dddbd8746644f2d1512c22fc1848b4b" "140734710354216". "2" "140734710354216"	"176630"
"017c6cee2948a2c99766b89b7920d812" "30000000" "1000000"	"30000000" "1000000"
"38a4e55f8e8403392c8ce62c2558759b" "1000000". "1000000"	"10000000" "1000000"
"4a5f2c30af1e4beba463acafdbe86046" "0".       "1"	"140734611095848" "2"

(Bold emphasis added by yours truly)

Cheers

J W

On second thought:

This is how the data looked in the backup version of the SQL file BEFORE changing to V 3.0, i.e. when accessed with V 2.6.19. 
Discrepancies in boldface:

"a091a44e7259b2b2fba207e14be6f2ea" "12823140" "1000000" "0"        "1"
"4da6ba68f004f65ce22ae2f4f738bb22" "30000000" "1000000" "20000000" "1000000"
"9d42cb293dc1952bdb99446ed708c0c8" "30000000" "1000000" "20000000" "1000000"
"8a5029c38e8255ef275c02063a87f5ea" "6994440"  "1000000"	"0"        "1"
"7d5225ed198029c094e8a69f86f1eee2" "30000000" "1000000" "20000000" "1000000"
"5ec50f6e6dc459952e2e04b01b9c27cd" "30000000" "1000000" "20000000" "1000000"
"301c90831e1af9e65bdaca358dbad40a" "30000000" "1000000" "0"         "1"
"fafd8b9b573e40b5224122eb1cc816e0" "30000000" "1000000" "20000000" "1000000"
"5dddbd8746644f2d1512c22fc1848b4b" "0"        "1"	"0"        "1"
"017c6cee2948a2c99766b89b7920d812" "30000000" "1000000" "30000000" "1000000"
"38a4e55f8e8403392c8ce62c2558759b" "10724808" "1000000" "0"        „1"

Puzzled ;)

J W
Comment 5 Jo Wetzig 2018-04-06 12:13:04 UTC
Please pardon the loss of boldface. It was present when I MAILED the response, but did not make in into the website bugzilla.

J W
Comment 6 John Ralls 2018-04-06 14:28:59 UTC
Hmm, interesting. Different results from Adrien's sample on bug 794936. (These look like dupes and his is older so I'm going to consolidate them. Please comment further on the other one.)

*** This bug has been marked as a duplicate of bug 794936 ***
Comment 7 John Ralls 2018-06-30 00:07:10 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=794982. Please update any external references or bookmarks.