> On 9 Feb 2019, at 11:20, Michael Hendry <[email protected]> wrote: > >> On 8 Feb 2019, at 17:37, John Ralls <[email protected]> wrote: >> >> >> >>> On Feb 8, 2019, at 8:11 AM, Michael Hendry <[email protected]> wrote: >>> >>> PS Looking at the log files, I’m reminded that a number of scheduled >>> transactions took place during the session. Inspecting these it seems that >>> each one is recorded four times - here’s an example extracted from the >>> larger of the two log file: >>> >>> ===== START >>> B aefe075a22d466826d4735afb8159c08 >>> cd4cb60c1e5a5294eb4e7d2623dbaebe 2019-02-08 00:03:46 +0000 >>> 2018-08-05 12:20:04 +0100 2018-08-05 11:59:00 +0100 >>> 9768413066e3e0d1272ba7839ea5f1cc b0e28c7d097d448b29f193895c973d63 >>> Amazon Prime Subscription n >>> 0/1 0/100 1970-01-01 01:00:00 +0100 >>> B aefe075a22d466826d4735afb8159c08 >>> f9d8cacc6b99135677ccc97ce6f4887d 2019-02-08 00:03:46 +0000 >>> 2018-08-05 12:20:04 +0100 2018-08-05 11:59:00 +0100 >>> 9768413066e3e0d1272ba7839ea5f1cc b0e28c7d097d448b29f193895c973d63 >>> Amazon Prime Subscription n >>> 0/1 0/100 1970-01-01 01:00:00 +0100 >>> ===== END >>> ===== START >>> R aefe075a22d466826d4735afb8159c08 >>> cd4cb60c1e5a5294eb4e7d2623dbaebe 2019-02-08 00:03:46 +0000 >>> 2018-08-05 12:20:04 +0100 2018-08-05 11:59:00 +0100 >>> 9768413066e3e0d1272ba7839ea5f1cc b0e28c7d097d448b29f193895c973d63 >>> Amazon Prime Subscription n >>> 0/1 0/100 1970-01-01 01:00:00 +0100 >>> R aefe075a22d466826d4735afb8159c08 >>> f9d8cacc6b99135677ccc97ce6f4887d 2019-02-08 00:03:46 +0000 >>> 2018-08-05 12:20:04 +0100 2018-08-05 11:59:00 +0100 >>> 9768413066e3e0d1272ba7839ea5f1cc b0e28c7d097d448b29f193895c973d63 >>> Amazon Prime Subscription n >>> 0/1 0/100 1970-01-01 01:00:00 +0100 >>> ===== END >>> ===== START >>> B aefe075a22d466826d4735afb8159c08 >>> cd4cb60c1e5a5294eb4e7d2623dbaebe 2019-02-08 00:03:46 +0000 >>> 2018-08-05 12:20:04 +0100 2018-08-05 11:59:00 +0100 >>> 9768413066e3e0d1272ba7839ea5f1cc b0e28c7d097d448b29f193895c973d63 >>> Amazon Prime Subscription n >>> 0/1 0/100 1970-01-01 01:00:00 +0100 >>> B aefe075a22d466826d4735afb8159c08 >>> f9d8cacc6b99135677ccc97ce6f4887d 2019-02-08 00:03:46 +0000 >>> 2018-08-05 12:20:04 +0100 2018-08-05 11:59:00 +0100 >>> 9768413066e3e0d1272ba7839ea5f1cc b0e28c7d097d448b29f193895c973d63 >>> Amazon Prime Subscription n >>> 0/1 0/100 1970-01-01 01:00:00 +0100 >>> ===== END >>> ===== START >>> R aefe075a22d466826d4735afb8159c08 >>> cd4cb60c1e5a5294eb4e7d2623dbaebe 2019-02-08 00:03:46 +0000 >>> 2018-08-05 12:20:04 +0100 2018-08-05 11:59:00 +0100 >>> 9768413066e3e0d1272ba7839ea5f1cc b0e28c7d097d448b29f193895c973d63 >>> Amazon Prime Subscription n >>> 0/1 0/100 1970-01-01 01:00:00 +0100 >>> R aefe075a22d466826d4735afb8159c08 >>> f9d8cacc6b99135677ccc97ce6f4887d 2019-02-08 00:03:46 +0000 >>> 2018-08-05 12:20:04 +0100 2018-08-05 11:59:00 +0100 >>> 9768413066e3e0d1272ba7839ea5f1cc b0e28c7d097d448b29f193895c973d63 >>> Amazon Prime Subscription n >>> 0/1 0/100 1970-01-01 01:00:00 +0100 >>> ===== END >>> >>> I don’t know what the significance of “B” and “R” is in the first column, >>> but the pairs of lines appear to be record the guids of the each >>> transaction and the accounts the split refers to. I don’t suppose the >>> appearance of Unix zero time (1970-01-01 01:00:00 +0100) at the end of each >>> line is of any significance. >> >> There's a header at the top of the log file titling the columns. It's >> >> "mod|trans_guid|split_guid|time_now|date_entered|date_posted|acc_guid|acc_name|num|description|notes|memo|action|reconciled|amount|value|date_reconciled" >> >> The codes for the mod field are: >> >> 'B' for 'begin edit' (followed by the transaction as it looks before any >> changes, i.e. the 'old value') >> 'D' for delete (i.e. delete the previous B; echoes the data in the 'old B') >> 'C' for commit (i.e. accept a previous B; data that follows is the 'new >> value') >> 'R' for rollback (i.e. revert to previous B; data that follows should be >> identical to old B) >> >> So GnuCash tried twice to create the two splits of the Amazon Prime >> Subscription transaction only to roll them back for some reason. >> >> Regards, >> John Ralls >> >> > > > Morning, John. > > Armed with the information above, I’ve been comparing the latest before-crash > log file with that created when I forced GC to open this morning. > > Here’s how the tops of these files look in MacVim’s split-diff mode: > > https://www.dropbox.com/s/tlk9xy7vstb7i0o/Screenshot%202019-02-09%2010.50.19.png?dl=0 > > and here’s how the bottom of the file looks: > > https://www.dropbox.com/s/8y5w0p8c7mf3oxq/Screenshot%202019-02-09%2010.52.17.png?dl=0 > > My guess is that GC is setting up all of my Scheduled transactions (“B” > lines) and then rolling them back (“R” lines) without committing them. > > There follows a series of four empty START-END pairs at line 643. > > This is then following at line 651 in the earlier file (on the right of the > screenshot) the one transaction scheduled to take place on the 8th of > February - but involving a Commit, then a Begin then a Commit. > > Today’s file (on the right) starts at line 651 with the same transaction and > the same Commit-Begin-Commit sequence, and then goes on to record the > scheduled transaction due for today. > > Each file ends with an orphaned “D” line, whose UID doesn’t appear earlier in > the file. > > This may be the expected behaviour, but it seems odd to me! > > Michael > > >
PS I’ve just realised that each of the B-R pairs occurs four times. I’ve been able to open and close GC four times this morning without incident. _______________________________________________ gnucash-user mailing list [email protected] To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
