Scanning w/ EPS Growth

The documentation for the EPS ticker property says

"The last reported EPS value for the security. "

So, it looks like the database only keeps the most current EPS data.

https://stockcharts.com/docs/doku.php?st=eps&id=scans:reference:ticker_properties

That suggests you cannot compare the current EPS number to previous EPS numbers. I tried

and [EPS > 251 days ago EPS]

but it doesn't pass syntax.

You could try Finviz.com to screen for PEG (if that's helpful)

finviz/screener/valuation/ sort on PEG column

or, if you hit the "Fundamental" tab, you can filter for PEG level

No, my powers are limited. My only connection with Stockcharts is as a subscriber, and with s.c.a.n. as a member and moderator. No administrative or policy role at all, anywhere.

Re your assertion "this data for sure is "in the package" of their feed(s) - I don't know that and I don't know how you know that. If you do, please share.

Also, as you probably know, Stockcharts originated as a charting site, not a database for retrieving fundamental data. There are plenty of those already. Theoretically, technical analysis does not require fundamental data at all, but evidently some people also want at least some non-technical data, so there is some. Whether they will follow through on evident plans to expand on that, I don't know. If they decide its a competitive necessity, I expect they will. To me, its irrelevant, except I do like to see the dividend yield (though not for timing purposes). But, if you can't make up your mind based on the chart, you (not you personally) may be using fundamental data as an excuse for not making up your mind, when all you really need to know is on the chart.

Thanks for the resume and the compliment.

While I respect your experience, I don't see where it says database design and management. That is a specialty. There's a lot more to think about than data structures. Maybe you already know this, but once you add or modify a data structure, you have to find and test every line of legacy code that touches those records. Any existing arrays that will include the new piece of data have get new parameters. Array references may have to be modified if data was moved (bad idea, but you might get forced into it). Variables have to be defined carefully. Libraries have to be updated. Dynamic memory allocations for loading and unloading the records have to be modified. Disk space has to be re-estimated and possibly reallocated. Response times may be affected. And so on. For sophisticated databases no change is a small change.

Development is nice, because you start with a clean slate. Maintenance takes a special kind of person because it is a completely different skill set and much harder (if you did bug reporting, you know).

So, considering the investment, there has to be a pretty good business case for changes. Does somebody else already do it better, are we losing subscribers because of it, would it attract new subscribers more than something else, etc., etc. As you probably remember, multiply any time estimate by two, and any cost estimate by three.