Invalid Benchmark Buy and Hold Symbol messagebox
Author: cmtn
Creation Date: 10/8/2017 8:44 PM
profile picture

cmtn

#1
I'm trying to move my strategies to a new, faster machine. I'm going from Windows 7 to Windows 10.

My options strategy works fine on the old machine, but not on the new one. Basically, the new machine gives a messagebox from GetExternalSymbol() saying "Invalid Benchmark Buy and Hold Symbol" and then throws an exception. The old machine did not show this box but would throw an exception so I could handle it. I handle it by trying another strike or expiration.

I've gone through the Preferences on the new machine to make it match the old preferences.

Also, I have checked the box "Update Data on Demand" on both machines.

Just to be clear, I do NOT want the message box.

I've condensed the issue down to this code to show the problem. The code below shows an expired option to prove the point. A valid option symbol would be: -AAPL171215P155. I don't get the messagebox on the valid option symbol. But, there isn't a sure-fire way to always know the proper option symbol.


Thanks.
CODE:
Please log in to see this code.
profile picture

Eugene

#2
1. A possible reason is when "Benchmark Buy & Hold" is activated in Wealth-Lab's Preferences and the B&H symbol is invalid (not found across your installed DataSets in the current bar scale). Entering a symbol that does not exist or has no data is a popular reason for getting this error message in backtests. Try to disable "Benchmark Buy and Hold Symbol" option.

2. You'd also want to rule out any expired/delisted symbols with 0 bars from your DataSet.

3. In case you run multi-symbol backtests, there's a live bug:
QUOTE:
(192679) Benchmark B&H Throws "Error processing symbol [last in DataSet]"
If no data exists for the first symbol in the DataSet for a Multi-symbol Backtest (Portfolio Simulation mode) and Benchmark B&H is enabled, the error appears and the simulation post-processing (visualizer) is aborted.
"Error processing symbol {last symbol} Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index"
profile picture

cmtn

#3
You can see from the attached png that buy and hold is not checked and has no symbol.

You can also see that I have one symbol in my dataset--AAPL. It has all of its bars.

I'm not doing multi-symbol back testing. I'm only testing AAPL.

Please keep in mind that I get the same exception on both machines. The difference is the new machine puts the exception in a messagebox. I"m trying to prevent the messagebox from showing.

I can't see any difference in my setup from my old machine. Do you have any other ideas?



Thanks
profile picture

Eugene

#4
There can be many factors in play like build to build difference, .NET framework difference (Win7 and Win10), presence of debugger installed, different 3rd data providers installed (yes, this matters with GetExternalSymbol/SetContext requests) etc. So for simplicity's sake, eliminating empty/invalid symbols in your DataSets might do for a start.

QUOTE:
You can also see that I have one symbol in my dataset--AAPL. It has all of its bars.

The idea is that "-AAPL170825P155" (or something) doesn't have the bars (i.e. has 0 bars). That's why my suggestion was that you'd want to eliminate them and thus get rid of the error.
profile picture

Cone

#5
The problem is that expired option data is not available from Fidelity. Use a symbol that has not expired, like -AAPL171020P155.

Or, if you want to test with that old symbol, look for the its .WL file in the C:\Users\[YOU]\AppData\Roaming\Fidelity Investments\WealthLabPro\1.0.0.0\Data\FidelityStaticProvider\Daily folder and copy it to the same location on the new machine.
profile picture

cmtn

#6
I used that expired option as an example. I could have used the current expiration but a bad strike to show the problem. The problem is the messagebox is being trapped by Try/Cath on the old machine but not on the new machine. There are going to be times when I don't know the exact strike price and need to try diifferent ones. Some increment in $5. Others increment $0.50. Every symbol is different.

On my old machine, I can loop through strike increments to find one that works because Try swallows the messagebox. On the new machine I can't do that because Try/Catch does not swallow the messagebox, so I need to click OK 20 times for each loop for each symbol.

Can you tell me why this code works on one machine and not the other? (Again, one swallows the messagebox, the other doesn't).
What do I need to change in my code to swallow the messagebox?
Or, do you have a way to prevent the exception with a function that returns only valid strikes for a given symbol/expiration?

Thanks
profile picture

Eugene

#7
QUOTE:
Can you tell me why this code works on one machine and not the other?

How can we, having no idea about your machines? See post #4, 1st paragraph. If it's not the lack of data (as per Cone's suggestion), you have to go through these items and find out what makes the difference.
profile picture

cmtn

#8
After taking break, I looked at this closer.

The exception on the Win7 machine which is caught without a messagebox is "Attempting to Deserialize an empty stream".
The exception on the Win10 machine which is caught with a messagebox is "Invalid Benchmark Buy and Hold Symbol".

Perhaps that is a clue that can lead to a solution. Why do the same symbols throw different exceptions?

Following up on #4:

QUOTE:
There can be many factors in play like build to build difference, .NET framework difference (Win7 and Win10), presence of debugger installed, different 3rd data providers installed (yes, this matters with GetExternalSymbol/SetContext requests) etc. So for simplicity's sake, eliminating empty/invalid symbols in your DataSets might do for a start.



-Both machines have WLP 6.9.17.0.
-Both machines have the latest .net 4.7 build.
-All WLP extensions have been removed from both machines and all preferences are the same, as far as I can tell.
-Regarding the debugger, would that help or hurt the situation? I get a lot of out of memory exceptions on the Win7 machine and a .net debugger messagebox appears. Is that a design of WLP or something I can turn on or off, and how do I do that?
-Regarding eliminating the bad symbols, that is the point. How do you know which strike is valid without testing by trapping an exeption? Do you have another way to do that?

Thanks
profile picture

Eugene

#9
QUOTE:
The exception on the Win7 machine which is caught without a messagebox is "Attempting to Deserialize an empty stream".

Runtime error: Attempting to Deserialize an empty stream is documented in the Wiki. If that doesn't help please search the forum for clues.

QUOTE:
all preferences are the same, as far as I can tell.

Preferences and data are considered the same when the files from the AppData folder are physically copied from one machine to another.

QUOTE:
Is that a design of WLP or something I can turn on or off, and how do I do that?

Invoking a debugger or not is usually a matter of preferences of your machine set by Windows or 3rd party software, not WLP (which does not have such option).

Good luck.

P.S. Just a side note:
QUOTE:
I get a lot of out of memory exceptions on the Win7 machine

Most likely caused by 32-bit WLP and/or Windows (and probably lack of RAM). They will go away after upgrading both Windows and WLP to 64-bit.
profile picture

cmtn

#10
Thank you, but while you were typing, I found that you have already solve the problem without knowing it.

When I said that I removed all extensions, I didn't notice the dropdown for "Other Extensions", so the two setups were actually not the same.

If your "Database provider by MS123 (Eugene)" is installed, the exception gets properly trapped. This provider was not installed on the Win10 machine.

Also, note the previous version of that provider threw "Attempting to Deserialize an empty stream". The new version throws "Value cannot be null".

If you have this provider installed on your machine, maybe you could reproduce the error by uninstalling it.

And, maybe you could take your fix code and put it in the next build of WLP to avoid this issue?

Either way, please don't change your Database provider. It is what solves this problem.

Thanks.



profile picture

Eugene

#11
This is sort of what I meant when mentioning this: "different 3rd data providers installed (yes, this matters with GetExternalSymbol/SetContext requests)". Wealth-Lab processes installed data providers in alphabetical order when looking up the data for symbols it can't find in the current DataSet - like with your invalid or inexistent option tickers. So the Database provider (for example) would get the call before FidelityStaticProvider, if installed.

Glad you resolved the problem. Whatever works for you is fine by me.