Increase maximum number of securities from 2000 to next level

busarch3

Please open up one more bit to increase the limit 8 fold - some of us have 30 years of data in quicken and are running against the 2000 securities limit. Thanks.

UKR

Until the programmers find a way to implement your request please review this relatively new feature: Archive Investment Transactions.

It might make it possible to lighten the load on your active investment account(s).

https://www.quicken.com/support/how-archive-investment-transactions

Also please review this discussion
https://community.quicken.com/discussion/comment/20086294#Comment_20086294

Whatever you do, please be sure to have or create a backup of your Quicken data file before you get started and/or work with a copy of your data file until you are sure the results are good.

Everyone, including the person who initiated this discussion …
If you would like to see this enhancement made in a future version of Quicken please don't forget to vote on it. Locate the big blue box near the top of this webpage (or page 1 for long discussions) and click the "Up" triangle under the voting count.
Wait a moment for the vote count to be registered and updated before you continue.
The little triangle changes from grey to black when you have registered your vote.
Adding extra comments helps, but does not increment the vote count.

Every vote counts!

For additional information about idea posts please read  https://community.quicken.com/discussion/7849425/creating-and-voting-for-ideas-in-the-community#latest

q_lurker

It is not clear to me what the current situation is for the historical "2000 trackable security" limit.  To my knowledge, no one has ever defined 'trackable'. 

The subscription program validation routines now make reference to 5000.  "Normal security references (up to 5000)"  No one has clarified if that replaces the 2000 limit or has some other meaning or is even a limit. 

Several users have cited their files as having significantly more than 2000 securities in the database. 

All in all, very much is unknown.      

Robert Ruman

Would someone please clarify this limit? After 25 years of using Quicken, I have 1950 securities and don't want the program to freeze.

Doug Giannotti

Bueller, Bueller

Mo B

Definitely needs to update security limits if Quicken is going to compete with new products

Chris_QPW

Out of curiosity I created a small program that created a QIF file that has 4000 securities in it and imported that into Quicken, and it did that with no problems.

So, the "limit" isn't just how many securities you have. What they mean by "trackable" is anyone's guess. I wouldn't be in the least bit surprised if no one even the developers know what that means.

Typically, the performance problems with lots of securities/security lots/transactions comes up way before anyone hits this limit.

davezechnich

thank you for all your notes above. I was concerned when I performed a "validate file" and the output said "maximum security reference: 446, number of securities 435." The agent at Quicken told me, "yes you are almost at the limit of the number of securities". the above discussion makes clear that information from Quicken was incorrect.

Chris_QPW

davezechnich

Feb 3, 2025

thank you for all your notes above. I was concerned when I performed a "validate file" and the output said "maximum security reference: 446, number of securities 435." The agent at Quicken told me, "yes you are almost at the limit of the number of securities". the above discussion makes clear that information from Quicken was incorrect.

"references" refer to how the database keeps track of the securities; it doesn't imply a limit. You will notice that there are more references than actual securities (which is normal). You can think of a reference as a "pointer to X". You certainly have more "pointers" than things you are pointing at (as in one or more of the references/pointers are pointing at the same security). The statement probably means something to the developers but is basically useless information for the user. I do wish they did a better job of putting out useful information in the Validate logging.

Mine are currently:

Maximum security reference: 229, number of securities: 228.

q_lurker

a) My statement from 5 years ago about 5000 securities seems no longer applicable. The Validation routine no longer includes that language.

b) My understanding of the relative meaning of the two current numbers is different than Chris's.

The "number of securities" seems clear enough. That should be how many you actually currently have in your file. Pull up the security list, show hidden securities, count the number. That should match what the validate routine reports for number of securities.

My understanding of Maximum security reference is that somewhere in the database records there is a record point to or referencing a security of that number. Some record is pointing at security 446, or 229, or in my case 1567. Any reference beyond the actual number of securities would be suspect, but the real problem they seemed to be looking for in making that check was big overshoots; a max reference to 12345 when there were 25 securities in the file.

I claim no structural knowledge of databases and how they work internally and offer the above simply as my understanding.

Chris_QPW

Note instead of counting the securities you can hold down Ctrl and Shift and select Help → About Quicken.

On the references, maybe I didn’t really state clearly what I meant. If references were less than securities I would certainly think that is a problem, but it really hard to know for sure why there would be more references than securities. When I think about it, it could be that part of the program reference the same security more than once or it could be that they just allocate references before they’re actually being used or maybe they referenced them and then you deleted the security and they don’t delete the reference because they leave it open for the next security that you might create. But that’s the whole point you’re presenting a log to should have information that is pertinent to the user. There are plenty of other hidden or hidden log files for the developers. This one pops up and is shown to the user. It should only contain information that is pertinent to the user as in presenting problems in their or just a statement that something is OK. It shouldn’t give and ambiguous information that might even just be useful to the developers.

q_lurker

With regard to counting the securities, I was really just trying to express that it was a clear, specific, determinable value.

I did some historical digging. In reference to a "Securities/Max ref" on the Ctrl-About Quicken display, Quicken Kathryn wrote in 2018 (copied from an archived post):

This is a recent addition, developed as a troubleshooting tool--we were finding that in some cases, investment crashes were due to out of range security numbers (i.e., the "Max Ref" number is far above the "Securities" number).  This discrepancy is typically caused by data damage, and we were seeing Max Ref numbers in the 50,000+ range, causing a huge memory resource drain and a crash.

So that was the source of my understanding. I went through a couple of tests. Created a new manual security with or without ticker. With each addition, both counts incremented by one. With the subsequent deletion, they decremented by one. In my file(s), the securities max and ref values always match. So I'm still not sure what a smaller or slightly larger reference count might mean.

Chris_QPW

@q_lurker Thanks, I had never seen that information from Quicken Kathryn, and it helps "somewhat".

It is basically impossible for us to really understand what a "reference" is exactly without seeing the code.

I mean I can take a pretty good guess that the "reference" a table in the database that points to the actual security record, and that they wouldn't be exactly the same for the same reason when you delete transactions you don't see a reduction in the size of your data file. In a database a lot of time it is better to just mark it "deleted" than to actually delete it. And then later reuse the "deleted records" first before allocating more.

But my basic problem with what they are doing is if you look at any of the other logs you have to go in and look for them, and as such there is the expectation that you are going to be looking at "debugging information". Whereas for Validate and Repair they pop that log up for the user to see every time. And if you look at a good some of what they put in the log that they show the user it tells them what to fix. Like bad transfers. That is the kind of thing that you should be presenting to the user. If the information of references and securities is only meant for the developer, then they should have at least stated that in the log.

Just think about how many times it has had to be "explained (but not really)" in this forum for the lack of that clarification.