Too many accounts for transfers, later ones alphabetically lost?

[Aaron Bilger]

Are there any known limitations on # of total accounts?

Or are there any known bugs related to transfer between accounts?

I've been using MS Money for almost 25 years, and have been on 'sunset edition' since about 2010.

Over that time, I've amassed a large number of accounts. I have roughly 80 open accounts. I don't even know how I could count all my closed accounts (trying to select one via the dropdown only shows me closed accounts from starting with letter 'A' to starting with 'E'). However, I'd estimate something like 300-400.

Recently I started having issues where transfer between accounts started failing, but only one side of the transaction.

For example, a couple months ago I added an account 'US Bank'. I added a transaction in it to transfer an initial deposit from another account 'Chase'.

This appeared to work fine, from the 'US Bank' side, showing me category 'Transfer: Chase'.

However, when I switched to the 'Chase' side, this same transaction showed up with an empty category. If I tried to change the category, I could select normal expense categories, including 'Transfer: xxx' from all my other open accounts. However, 'Transfer: US Bank' was unavailable and impossible to select. If I tried to manually type that full text, it would be unrecognized as a valid category.

The 'US Bank' account appeared usable otherwise. It reliably showed up in the account list. Bills could be setup to use it. Transactions in it did appear in reports. Just it could not be used as a 'Transfer : xxx' source or destination.

I could not figure any reason for this, and was unable to solve it. I had to workaround it by adding 2 separate transactions - one outgoing from Chase to an expense category, then one incoming to US Bank from that expense category. This 'works', but unfortunately loses the key fact that it's a transfer.

I added another account 'Citi' about a month ago, and it seemed to work fine.

Today, I added 'Wells Fargo' - and it has exactly the same problems as the account 'US Bank'. It is not possible to select 'Transfer: Wells Fargo' as a category in any other account. And if I go to my Wells Fargo account and enter a transfer from another account, the transaction's category will incorrectly be blank when I go to that other account.

It's now clear that MS Money is limiting accounts available for 'Transfer : " alphabetically. If I add a new account 'Sam', it works fine fine for transfers. A new account 'Vince' will not. The cutoff for me is currently around accounts starting with 'T' or 'U'. 

I've searched online and seen claims that MS Money supports 'unlimited' number of accounts, and that various users report using 500+.

However, I'm assuming the behavior I'm seeing means there is some form of limit on number of accounts, at least in whether they can be used in transfers. This also makes me worried that there may be other limitations (or bugs) lurking related to high number of accounts that I've just not encountered yet.

So:

1 - Have others encountered this particular behavior?

2 - If so, do you know more details - e.g. exact # of accounts where this starts happening, if there's a real workaround (not just losing transfer capability with the affected accounts), or if there are other related limitations or bugs?

3 - If not, do you have any recommended config settings, workaround attempts, or even pure info-gathering experiments you think I should try?

Thank you!

Aaron

[Cal Learner]

3. Confirm that you had  put the patched version of mnyob99.dll into place in  MNYCoreFiles

If that had been done, I  would try file repair. 

File->RepairMoneyFile->QuickFileRepair.  

That is simple, but it probably will not solve this. 

If that does not fix it, I would try making a repaired version of your file with
File->RepairMoneyFile->StandardFileRepair level 2

[Cal Learner]

It's now clear that MS Money is limiting accounts available for 'Transfer : " alphabetically. If I add a new account 'Sam', it works fine fine for transfers. A new account 'Vince' will not. The cutoff for me is currently around accounts starting with 'T' or 'U'. 

Interesting observation.  If the repair does not help, consider a workaround by  renaming the closed "Ajax Bank" to "ZZZ Ajax Bank" etc.

[Aaron Bilger]

I've previously tried both Quick File Repair and L2 Standard File Repair. No change in behavior (and oddly, the repair process said no issues found, even when some transactions with an empty category on only 1 side remained).

However, I did not know about a post-sunset edition patched DLL!

Where can I get an authoritative/trustworthy patched version of  mnyob99.dll ?

Thanks!

[Bill & Michelle Becker]

This site has an explanation of how to replace the mnyob99.dll with a patched version and a link to the patched dll:

https://microsoftmoneyoffline.wordpress.com/2012/12/02/windows-8-64-bit-version-compatibility-with-sunset-money/

--
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 visit https://groups.google.com/d/msgid/microsoft-money/342621b3-1bb4-4e5b-a172-63e8f035ad75n%40googlegroups.com.

[Cal Learner]

The origin of this patch is very interesting.

https://devblogs.microsoft.com/oldnewthing/20121113-00/?p=6103 describes it. 

I note the "Update:" that mentions Windows 8. I had not seen that before. I wonder how that would have worked, and if that made it to Windows 10 and 11.

[Aaron Bilger]

Thanks!

I especially appreciate it had hex editor instructions, so I didn't have to download an unknown binary, and could confirm I had the correct starting version.

Unfortunately it had no effect on the account transfer behavior.

[Aaron Bilger]

That's awesome, thanks! I love the detailed background and getting into the x86 assembly!

I've actually never had any other compatibility issues with MS Money sunset edition, and successfully used it without ever needing the patch, from XP 32-bit to Win7, Win8, and now Win10 64-bit.

[Cal Learner]

Did you try a workaround by  renaming the closed "Ajax Bank" to "ZZZ Ajax Bank" etc? I would experiment with a copy of my *.mbf with a different name.

For backups, I have the upon-exit backup keep the latest 25 and the scheduled backup to keep the latest 12 *.mbf files to a USB flash drive. My scheduled backup is set to every 6 days, but I ticked "Ask me before backing up", and in practice only save that scheduled backup after I have imported the OFX files via PocketSense on Saturday.

[Aaron Bilger]

TL;DR:

1 - As best I can tell this is a bug with how MS Money enumerates accounts to generate the list of possible 'Transfer : xxx' for the Category dropdown box

2 - This is irritating, but as best I can tell there's not an actual loss of source or destination account data in the affected transfer transactions

Tests:

- Finally isolated the cutoff of issues on my data between 2 'US Bank' accounts. 1 of these accounts (earlier alphabetically) was available for transfer from other accounts, the other was not. Initiating a transfer in the 2nd US Bank account from another account would appear to work - but then the other side of the transaction would show the category as blank rather than as a transfer.

- Renamed 1 other open account starting with a 'C', to just the letter 'Z'

- All transfer transactions involving this renamed account immediately got their category blanked out! It was now impossible to select (or manually type) a transfer to this 'Z' account

- However, the 2nd US bank account now worked for transfer transactions! It now appeared as a valid transfer destination in other accounts.

- Most importantly - *existing transfers which had been setup from the 2nd US Bank side had been preserved* i.e. before the rename, these transactions would appear broken on the other account side, with a blank category. Just renaming the lower alphabetical account to 'Z' meant all existing transfers involving the US Bank account appeared correct, from both sides of the transaction.

- Regression test - renamed 'Z' back to 'C' - Transfers involving 2nd US bank account immediately showed blank category again. However, transfer transactions involving the 'C' account had their category reappear, with correct account values on both sides.

- Repeated above cycle of tests, but using a closed account starting with 'C' rather than an open one, with same behaviors

I believe this all means that:

1 - MS Money must be using a large enough account ID (not just 8 bit : ) ) such that I'm not hitting a true hard limit on # of accounts, or having accounts dropped, aliased, or other very bad behaviors

2 - Transfer transaction data must be preserving source and destination account IDs correctly, even when the relevant transfer categories cannot be selected or displayed

3 - However, there must be a bug where the enumeration/generation of available 'Transfer : xxx' destinations, *is* limited, cutting off after some count (256? 300-400ish? I can't easily get a count of where exactly the cutoff is since it involves closed accounts which I can't manually view or enumerate)

4 - This transfer destination enumeration must be going through all accounts alphabetically, regardless whether account is open or closed

So with all this, I am cautiously optimistic that renaming closed accounts to 'Z - old account name' is a safe workaround.

It should allow more open accounts to be used as transfer destination.

And (I'm 95% confident on this part) existing transactions involving the closed, renamed account are preserved.

After seeing the details on that DLL patch, it might be fun to fire up the debugger, to try to find the assembly for transfer destination category generation and fix it :).

In any case, I would love to know if my findings generalize for others. If anyone has 'too many' accounts such that transfers are getting lost, I hope this helps.

And thanks for the suggestions!

Aaron

[Cal Learner]

In any case, I would love to know if my findings generalize for others. If anyone has 'too many' accounts such that transfers are getting lost, I hope this helps.

How many accounts do you count as being too many?

I just counted... 24 open and 20 closed, for a total of 44.  Many of these are not actual accounts at institutions, but I have watch accounts and things like my InTransit account that let each end of an actual transfer have different dates.

Also, an investment account can also have an associated cash account-- even watch accounts. My counts did not take that into account.  So that associated cash account might count toward the hidden limit that you have discovered.

Nice job of characterizing.

[Aaron Bilger]

I wish I could find the exact # of accounts. But as you say, the counting has some ambiguity. And AFAICT there is no practical way to view and count all closed accounts, which mostly disappear off screen from the selection menu.

Good point on investment accounts. I haven't tested this (e.g. does renaming 'E-Trade' to 'Z-Trade' open up 2 slots for other accounts to be enumerated for transfers, rather than just 1), but the behavior seems like each must be literally 2 accounts just with a special linkage.

Business accounts may also multiply. I have or have-had several small businesses, each of which get at least accounts for invoices/AR, and sales tax.

There's also some question on frequent flyer accounts. These behave sufficiently differently such that I assume they are stored in a separate table from other accounts and wouldn't count in any enumeration, but I'm not certain of this.

I see I have 76 open 'normal' accounts.

I believe 13 of these are retirement/brokerage/529/etc accounts, so likely 13 extra there.

I have at least 6 additional accounts due to open or closed businesses.

For normal closed accounts, I can only estimate. On my 4K monitor, 80 fit onscreen in the closed account drop down list. Based on where it is in the alphabet at the bottom, I'd estimate I have about 100 more.

Best guess is about 25 of these were investment accounts, for 25 more.

I have 25 open frequent flier programs, and 13 closed ones.

So assuming FF programs don't count, my best estimate of total # of accounts = 76 +13 + 6 + 80 + ~100 + 25 = ~300. Add another 38 if FF counts.

Based on this, and the fact that the enumeration failure point is late in the alphabet for me, I'd estimate around 250. Best guess would of course be 256 then.

Aaron

[Cal Learner]

I just found an easier way to count accounts. Open the "Account balances with details" report.

Either Copy the report (by right-clicking into the report), and paste into a spreadsheet, or Export the report to Excel as a CSV. 

Either way, the report for me had its last header line on row 5 and the last account on row 72. So I have 72-5=67 accounts counting associated accounts which each get their own line.

When the report is Reset, both open and closed accounts are included.  With Customize, one of the choices is to only include All Open Accounts. When I did that, I went down to 38 accounts.

[Cal Learner]

I also note that the list in the  "Account balances with details" report  defaults to be in alphabetical order. So if 256 work, the one on row 256+5=261 would work, and row 262 would not.  Another thought that it might be the first 255 that work.

I then notice that the Watch accounts are not included in the report. I went to a Watch account Cash accout, and tried to enter a transfer of $1 to a non-watch cash account (my InTransit), and it worked. I went to the InTransit, saw the new Transfer, and added a transaction to transfer $1back to my Watch (Cash). Thus things seem to be complicated by Watch accounts.