Quicken Calendar not displaying recorded transactions from one account

pscampbell

I am a LONG TIME Quicken user and this issue suddenly popped up for me a few days ago. I spent hours on line with tech support doing many backups, validate, super validate, file copies, etc, to no avail. After doing some more trial and error, I finally discovered the issue. I cut and pasted a few transactions from the non-displaying account into a new account, and the calendar suddenly started showing transactions from the old account. But as soon as I put back some of the transactions I had cut, it stopped again. I realized the failure happened whenever the register went above 32,768 transactions, at which point no transactions would show in the calendar. But with 32,768 transactions or below in the register, they all showed up on the calendar.

The solution was thus to create a new account for all new transactions going forward, transfer the balance from the old account to the new one to zero out the old one, and start recording new transactions in the new account. Both of these accounts now show all transactions in the calendar.

I turned to Chap GPT, which explained the following:

Calendar view fails silently when an account exceeds 32768 transactions due to a legacy fixed-size transaction index. Data remains intact but calendar rendering aborts instead of truncating or scoping.

1. Maximum record or list limits

In older versions of Quicken (especially pre-subscription and early Windows/macOS builds), 32768 was often the maximum number of items allowed in things like:

• Memorized payees
• Categories or splits
• Transaction list indexing
• Internal flags or IDs

That limit came from using 16-bit signed integers, where:

• Max positive value = 32767
• Sometimes 32768 appears as an overflow boundary or internal cap

So when users hit “too many” of something, Quicken would quietly break, slow to a crawl, or throw obscure errors.

2. String / field length constraints

You’ll sometimes see 32768 referenced in:

• Notes fields
• Memo text
• Import/export limits (QIF, OFX, CSV)

That’s because many legacy systems capped text blobs at 32 KB (32 × 1024 = 32768 bytes).
Anything beyond that could:

• Be truncated
• Corrupt the file
• Cause sync failures

3. Why Quicken users still run into it today

Even though modern Quicken versions are 64-bit:

• Old limits are baked into the file format
• Decades of backward compatibility keep those constraints alive
• Imported data from banks or older files can still trip the limit

This is especially common if you:

• Have a Quicken file that’s 10–20+ years old
• Imported massive transaction histories
• Use extremely detailed split transactions or notes

UKR

This seems to be the same issue as this one, reported a few months ago:

Bills & Income Projected Balances Seems to Stop Working Properly when I exceed 32768 transactions — Quicken

Your solution, to create a new account register for new transactions, seems to be the only feasible workaround at this time, until the programmers can tell us if they can band-aid-quick-fix it or not.