Updates for "earning per share" are not showing up in the Data Manager logs for the Fidelity static provider. It's my understanding everyone else is getting them, so my system is at fault somehow. All other static updates, like "estimated earnings updated" are working fine. On-demand updates are working fine.

I seriously doubt the problem is in the *.WLF files because I'm adding new symbols in the WL datasets constantly, so new *.WLF files are always being added. But nothing about "earnings per share" for any stock is showing up in the Data Manager log. The log doesn't even show that the "earning per share" provider is even attempting to update.

I have Data Manager check boxes for [1] Fidelity Investments, [2] Equity Summary Scores, [3] Fidelity Estimated Earnings Data for Securities, and [4] Fidelity Fundamental Data for Securities all checked. I have tried toggling these check marks on and off restarting WL between. That didn't help.

Is the problem in the WL *.config file? If so, which item in there needs adjusting?

Hi Mark,

I recall you had an EPS issue last month:

FundamentalDataSeries("earnings per share",...) throws FormatException

Apparently it's either incorrect FundamentalDataSeries aggregation and/or "corrupt" Fidelity data. It's an interesting observation that on demand data update is working fine. I'll add this to the already existing bug report.

As long as [4] is checked I doubt that there's a WL config issue.

QUOTE:
The log doesn't even show that the "earning per share" provider is even attempting to update.

Hmm, what I'd try is delete the cache folder for the fundamental provider in question and retry update:

C:\Users\Windows username\AppData\Roaming\Fidelity Investments\WealthLabPro\1.0.0.0\Data\..

QUOTE:
As long as [4] is checked I doubt that there's a WL config issue.

It's checked, but I'm not sure that's even required. If I remember right ... I "think," when I first started using WL, I never had [4] checked, but I still got "earnings per share" updated in the Data Manager log. There was a period of several months ago when I had it unchecked. But it's been checked for the last two months. Do you think unchecking it started this problem?

QUOTE:
I'll add this to the already existing bug report.

But I think this problem is unique to me. Are you suggesting my action of unchecking [4] Fidelity Fundamental Data for Securities for several months, then re-checking it for two months created this problem? Is that the bug that's being reported? I was kind of thinking something isn't getting reset in the *.config file when the check box gets re-checked.

So what in the *.config file gets changed when [4] Fidelity Fundamental Data for Securities gets re-checked?

QUOTE:
... I'd try is delete the cache folder for the fundamental provider in question and retry update

But new stocks, which don't have any existing *.WLF files cached are getting added all the time. If it was the *.WLF files, then all the new stocks would be working since [4] was re-checked.

I'm not convinced we know what the real problem is yet.

It's my understanding the only fundamentals that get saved to disk are earnings-per-share and estimated earnings. All others are simply saved in volatile RAM memory but not stored on disk. Is this correct?

QUOTE:
But new stocks, which don't have any existing *.WLF files cached are getting added all the time.

By virtue of on demand data update enabled, I guess.

QUOTE:
Do you think unchecking it started this problem?

I think that "earnings per share" is part of what's offered by "[4] Fidelity Fundamental Data for Securities".

QUOTE:
I think that "earnings per share" is part of what's offered by "[4] Fidelity Fundamental Data for Securities".

In that case, then the "bug" is once you turn [4] off, it's not possible to turn it back on again by re-checking the box with on-demand updates enabled. Report that as the problem.

I'm wondering why that is a problem? The check box "stays checked" once I re-check it, so it's getting registered okay. There must be an internal state that's not getting re-enabled after the box gets re-checked. The developer should eliminate that "redundant" internal state.

For a moment, I was thinking on-demand updates might be interfering with it. But I only visit 15% of my stocks in my datasets each day, so 85% of them should be getting static updates, which is not happening.

What's the difference between the FidelityFMDFundamentalProvider and FidelityWSODFundamentalProvider directories? Which directory has the earnings-per-share data? Look at the Modified Date stamp and file sizes in the attachment and see if anything doesn't look right to you.

QUOTE:
What's the difference between the FidelityFMDFundamentalProvider and FidelityWSODFundamentalProvider directories? Which directory has the earnings-per-share data?

"WSOD" stands for Wall Street On Demand. I guess that FidelityWSOD* delivers the majority of fundamental data items except ESS and split/dividend. My understanding is that FidelityFMDFundamentalProvider is the provider for the split/dividend data. Being irregular (split) and quarterly (dividend) data they don't consume much space. So the file size ranging from 1KB to 9KB does not appear to be an issue. Neither are some timestamps in the past for e.g. OA, OAPH, OEUH because those symbols ceased trading.

QUOTE:
In that case, then the "bug" is once you turn [4] off, it's not possible to turn it back on again by re-checking the box with on-demand updates enabled. Report that as the problem.

Honestly I don't think it's the problem. Nonetheless you can try a "fresh start" to verify:

1. Shut down WLP
2. Rename the WealthLabPro folder at: C:\Users\Windows username\AppData\Roaming\Fidelity Investments\WealthLabPro\ to something like WealthLabProX
3. Start WLP, check all the Fidelity fundamental data providers and run "Update All Data"

If it works well, I'd revert to the WealthLabProX backup with a few omissions: without WealthLabConfig.txt and the Fidelity fundamental data folders.

QUOTE:
some [*.WLF] timestamps in the past [very old] for e.g. OA, OAPH, OEUH because those symbols ceased trading.

So you're saying when you press the Delete Symbols button on the Fidelity Data tab of Data Manager, it only deletes those symbols in the datasets, but it does not delete any of the cached data (like *.WLF files) on disk. I didn't know that. It would be nice if it did. (Not a high priority fix, though.)

QUOTE:
If it works well, I'd revert to the WealthLabProX backup ... without WealthLabConfig.txt and the Fidelity fundamental data folders.

I'm assuming you mean without the FidelityFMDFundamentalProvider and FidelityWSODFundamentalProvider folders, but keep all the others.

I did discover the "devenv.exe /diff" utility in Visual Studio so I can compare WealthLabConfig.txt.new with WealthLabConfig.txt.old. I would like to get to the bottom of this problem if you're willing to fix it. There are times when the WL application ABENDs when it asks you to refresh your password and you don't do it in time. I know files like WealthLabConfig.txt don't get closed properly when that happens. If you could fix that password-refreshing ABEND problem, that may fix many other things. Any ABENDing problem is a high priority fix.

You could also write-through all changes--immediately--to disk of the WealthLabConfig.txt file (i.e. write-through caching). Then it won't be sensitive to ABENDs. But fixing all the ABEND causes would be the preferred solution.

QUOTE:
So you're saying when you press the Delete Symbols button on the Fidelity Data tab of Data Manager, it only deletes those symbols in the datasets, but it does not delete any of the cached data (like *.WLF files) on disk.

WLP/D does not delete the cached data by design.

QUOTE:
I'm assuming you mean without the FidelityFMDFundamentalProvider and FidelityWSODFundamentalProvider folders, but keep all the others.

Right, that's what I'm saying.

I'm finally getting around to following up on this "earnings per share" static download problem. I tried your suggestion in Post# 6:

QUOTE:
1. Shut down WLP
2. Rename the WealthLabPro folder at: C:\Users\Windows username\AppData\Roaming\Fidelity Investments\WealthLabPro\ to something like WealthLabProX
3. Start WLP, check all the Fidelity fundamental data providers and run "Update All Data"

And I still cannot get "earnings per share" to update in the static download log, although everything else (like "estimated earnings updated") works just fine. The update log doesn't even show it "attempting" an earnings-per-share update on anything. What can be wrong?

I'm beginning to wonder what's left to try? Is there something wrong with my WL install? This earnings-per-share static update problem existed under WL 6.9.19.X. When going to WL 6.9.20.7, I did a fresh install (retaining the same AppData directory, of course), and that didn't fix the problem either.

Please look at the attachment of the WL 6.9.20.7 install directory and check the date and file size of the DLLs that are responsible for performing the static earnings-per-share update. Do they look corrupted? How can I tell if these DLLs are loading?

I wonder if I try updating in the Administrators account (instead of my User account) if that would help?

Nothing suspicious in your WLP installation and (in particular) the Fidelity fundamental provider suite that works in general.

1. Data Update Log aside, how actual are your Fidelity "earnings per share" items now?
2. What do you mean by updating in the admin account? Are you used to either update the data in different user accounts?
3. Is on demand update activated?

QUOTE:
1. Data Update Log aside, how actual are your Fidelity "earnings per share" items now?

Well, it's interesting you ask that. Prior to trying what's in Post# 2, on-demand was missing the most recent earnings-per-share data point. After reloading the entire data cache (including price data), that problem seems to have disappeared; I'm not sure why. But the static update log still does not show any "attempt" to update any static earnings-per-share data. About a year ago, I use to see static earnings updates in this log.

Unrelated, but the other thing reloading the data cache fixed is the display of the wait hourglass. Before the cache reload, the wait hourglass was never displayed when WL was busy. I'm not sure what's going on there. Perhaps reforming/resetting the WealthLabConfig.txt file fix that--weird.

QUOTE:
3. Is on-demand update activated?

Yes, it's always active. Are you suggesting on-demand updating is inhibiting static earnings-per-share updating? If so, it never use to do that a year or so ago.

QUOTE:
2. What do you mean by updating in the admin account? Are you used to either update the data in different user accounts?

No, everything is being done (including static updates) in my Windows user account. Even Visual Studio builds are done in my Windows user account. (Executing the VS memory profiler does require a privileged account, but I rarely run that.)

The only thing the admin account is used for is installing/removing software. That includes running WL Extension Manager since that requires privilege to write into the WL install directory (which is owned by Administrators). And that's always been the case for the last four years I've used WL.

I only mentioned the Administrators account because I'm wondering if WL is trying to write into its install directory--which is protected--when performing a static earnings-per-share update in a Windows User account. If it is, then that's a security bug that needs correcting.

---
Thanks for checking my WL install directory. Everything does appear to run well except static earnings-per-share updates.

To recap: on demand update is always active, reloading restored only the latest EPS but the historical EPS data is missing (b/c updates don't start)? Please double check that all the Fidelity fundamental provider entries are checked in the Data Manager > Update Data > Fundamental data providers.

Look at the screenshots and directory attachments and tell me if anything looks wrong. Is there an attachment I forgot to post that might help?

From the directory attachments, it appears they are populated, but are they populated by the on-demand provider or static provider? Is there a way to tell? At any rate, the static provider log doesn't show anything for earnings-per-share updates.

I have to wonder if anyone is getting static provider updates for earnings-per-share? Perhaps they think they are, but they are really not. Perhaps the on-demand provider is hiding this problem (like with the summary score provider).

@Cone will correct me if I'm wrong. Not sure if EPS, being one of the many items from the Fidelity fundamental provider's batch, should have its own line in the log. The directory listing tells that the EPS data is up to date. Apparently populated during today's 7:00am scheduled update, if I'm not mistaken.

QUOTE:
I have to wonder if anyone is getting static provider updates for earnings-per-share? Perhaps they think they are, but they are really not. The on-demand provider is hiding this problem (like with the summary score provider).

I'm successfully getting Fidelity's "earnings per share." I update each morning between 6:30 and 7:30 am EDT. "on-demand"is off. "earnings per share" is not called out in the log.

From time to time I run a script I wrote in 2014 when I was having fundamental data issues. I ran it just now on the 1,190 symbols in my universe.
The debug log shows...

QUOTE:
Checking earnings per share
Data not up-to-date: PCMI
Data not up-to-date: TSS
Data not up-to-date: WAGE
Oldest, dated 4/18/2017->AABA
Most current, dated 9/17/2019->ADBE, CBRL, FDX
Late? (5 symbols > 107 days): AABA AZO COST SMCI USAT

Three symbols had updates yesterday and five are overdue.

The script is below. The fundamental being examined is hard-coded(fname). Any fundamental works, not just Fidelity. (I really shouldn't just keep giving these scripts away. lol).
Parameters:
Late days: the fundamental is considered overdue for a symbol if the most recent date is older. I use 107 to get reasonable results.
Verbose: When set to one, the most recent value is displayed for each symbol. Otherwise, only a summary is shown.

CODE:
Please log in to see this code.

QUOTE:
I'm successfully getting Fidelity's "earnings per share." I update each morning between 6:30 and 7:30 am EDT; on-demand is off. "earnings per share" is not called out in the log.

Interesting. Well, "earnings per share" use to be logged in the static update log, and was in WL 6.9.19.X. I remember seeing it a year or two ago.

The good news is "earnings per share" is being updated. If on-demand is off during the updating, then it must be a static update without logging it into the static update log anymore--strange. I didn't know this change was made. (I wonder why they change it?)

Thanks for all the help guys.

Good, I guess the problem is resolved now.

@Cone will have the final say on whether "earnings per share" should be part of the data update log. For all practical purposes, it doesn't make much sense to be verbose about every fundamental item when a fundamental provider returns dozens of items. Of course it's different when a dedicated fundamental provider returns only one or two items.