nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Auto-Replacing TXFR check numbers with "TXFRúÿÿÿ"

k_man81

I suspect it's a sign of a memory issue, but I keep having a few hundred of my recent transfers changing their check number from "TXFR" to "TXFRúÿÿÿ".

I can do a search & replace, and it seems to fix it - until the next time I open Quicken.

I do have a very large quicken file (20 years worth of data, 350MB+). So, guessing that's a factor. But I would think after changing values back to TXFR it would stick - but it doesn't.

Find more posts tagged with

Comments

RalphC

The size and/or age, by itself, would have nothing to do with display errors. My data file is easily 25+ years old and twice the size of your data file. In the past, it's been 4 times your size without any errors.

First, have you tried validating/super-validating your data file?

The second troubleshooting step would be to create a new test data file and see if you can duplicate the results with test transaction entries. That'll define whether the issue is with the program, or with the data file.

k_man81

@RalphC - Thanks for the ideas! I have validated/super-validated.

I'm quite sure there's something with the data file - I wish there was an easy way to export transactions, etc. into a new data file (some sort of a "start fresh" idea). But, I have no idea what it could be, or how I could try to clear it up.

The oddity to me is that it's always the same extra 4 characters… Almost like something is reusing memory at some point. But, it's not 100%, because there are transfers that are 100% fine intermixed with the transfers that have this wonky value…

UKR

The same problem has been discussed off and on in the past.
It's my understanding that Quicken uses a small table to contain the "NUM List" entries.
Somehow, the table entry for "TXFR" has been damaged.
None of the Validate and Supervalidate routines are programmed to fix the table entry.
Each transaction in your registers indirectly points to an offset into the NUM List table, retrieving the same corrupted entry every time.

Until we can get the programmers to somehow fix the damaged table entry the only solutions I can think of might be

try to use Edit / Find/Replace to find all garbled TXFR in the Check# field and replace them with a blank space
or
to create a copy of your data file: File / Copy … / Create a copy or template. Store this file under a different name in the same folder as your current data file.
As a side effect of creating a copy, the NUM List should now be clean, but all your online connections to your banks will have been reset and need to be reestablished, one bank at a time.

Rocket J Squirrel

3. Create your own new item in the Num list (e.g., "XFER") and replace all the bogus num strings with your new one.

4. Narrow the Check # column so you can't see the trailing bogus characters.

😁

k_man81

@Rocket J Squirrel - I love it!

"4. Narrow the Check # column so you can't see the trailing bogus characters."

You've definitely been using Quicken for a REALLLY long time! 🤣

Rocket J Squirrel

https://community.quicken.com/discussion/comment/20395959#Comment_20395959

Yes, the longer you use Quicken, the wackier the workarounds that come to mind. 😜

k_man81

Just to "tie a bow" on this… I did end up making a copy, and that seemed to work and I was able to truly remove the weird TXRF check numbers…but…in re-setting up all the online accounts, Quicken linked the wrong accounts, which got things into a funky state, and I lost my will to keep fighting… :(

So…I may try the "copy and start from scratch" sometime in the future… But probably only on a day where all the On-Line accounts seem to be working good, and my patience level is extra high… :D