Tip: if you will use a new Money Market Fund, define it in Money first.

[Cal Learner]

A Money Market Fund (MMF) is a special mutual fund with the price fixed at $1. If you use PocketSense or other method to download OFX broker transactions, the OFX uses "MF" for both. So if you download, and let the new MMF investment , such as Fidelity FZDXX or SPRXX  or Vanguard VMFXX or VMRXX get created automatically, it will be forever defined as a mutual fund. Not terrible, but not ideal.

So define first in Money before buying the MMF for the first time.

[Dick Watson]

As Cal notes, the only difference between Mutual Fund vs MMF investment type in MS Money is that the Mutual Fund will always want a share price for Money investment transactions and for the MMF Money will always assume $1. OTOH, I've had at least one MMF (FTEXX) distribute a LTCG--which Money won't accept as an investment transaction activity type for an MMF.

[First Last]

Some low-level stats when you perform nuke-the-bills

My msmoney current size 131MB

Perform nuke-the-bill, the size remains the same 131MB

But there were some changes in the low-level data structures

See this shared spreadsheet

https://docs.google.com/spreadsheets/d/1D5b-iYCGr-xd-5gkSJq9QF-fLAL8hIT_0zIkWRROYao/edit?usp=sharing

Namely in 

BILL table: 286 rows were removed (expected)

TRN table:559 rows were removed (not expected)

TRN_SPLIT table: 160 rows were removed (not expected)

TRN_XFER table: 138 rows were removed (not expected)

Pure guessing:

My suspect the speed-up after the nuke-the-bill is due to how msmoney manages its bills. It does so by using the "bill" as a template then creates transactions as needed based on the scheduling rules (weekly, monthly ....). 

I think msmoney does this pretty inefficiently and involve a lot to scanning so the more bills there are and the more bill's related transactions existed and more work needs to be done thus causing progressive slow down.

 

[Dick Watson]

The size of my file immediately after the Nuke I just did to a copy grew from 111,852 kB to 112,164 kB. I would not be surprised, indeed would expect from past experience, that it would shrink by a couple of meg upon a couple more uses via compact on exit.

The schema for bill stuff is a mess. It's the one area I feel like I understand the least of the ones I've worked on, and probably spent the most time working on besides. There seems to be lots of stuff they do to allow the exceptions-in-series capability, the show past instances of bills as entered as transactions, and the detect recurring transactions capability. (I think the phantom TRN* stuff you see deleted after a Nuke is part of the first two of these implementations. Every Bill series and its exceptions store scheduled transaction info, just like real register transactions, as required in TRN* tables. Plus, other entries remain there that are not real transactions, but aren't current bills either. What they are is a mystery to me.) I also think there may be some stuff they store in TRN* to make cash flow projection from bill series easier.

It might have made sense to the folks who designed it. I wanna think. OTOH, that they added the Nuke feature suggests they knew it had, ahem, issues. I've always suspected that Nuke was added because they knew Bills had issues but no longer had enough budget to fix the underlying issues. So, Nuke was the second-best thing they could think of.

… 

[joe dempsey]

My experience is that nuking the bills does not reduce the file size - at least not immediately but it certainly speeds up the opening time

[Mark Fields]

I first performed a "Nuke the Bills" ;-) operation in 2007.  My file size was not big but I was running Win 95 and it was a different era of speeds.  I made this spreadsheet because it was a lot of work and I wanted to see if it was worth it.  It was.

I next did a nuke process in 2020, almost  3 years ago.  Again the results were astounding in terms of performance.  When I look at the performance improvement as measured by the times, the short term pain and time to perform the process is gained back in perhaps a couple weeks.  I never measured the "time to close the file" but anecdotally I say it is noticeably better (hmm..two prepositions).   Also I did not measure how many bills were in the bill planner before and after.  Sometimes I've had a bill that was in the planner and the expense went away, such as a car payment, or perhaps something I bought that was 90 days, or an expense that went away for say lawn service that I switched vendors, etc.

Here's the before and after data.

--
You received this message because you are subscribed to the Google Groups "Microsoft Money" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microsoft-mon...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microsoft-money/49a19358-77f9-4bb5-88a1-b910ec74f3f6n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dick Watson]

I've never collected objective metrics, but this matches my qualitative experience with Nuke The Bills. I suspect others see differing results because of their differing patterns of how they used/created/edited/used series exceptions/deleted Bills over time.