I have some strategies that make use of Bloomberg fields.

Examples of this are INDX_ADV_VOL or INDX_DECL_VOL of well known equity indexes such as SPX, BE500 etc.

When I launch the strategy all works well. The series get populated.

When I press 'Go' then they are all gone, i.e. filled with zeroes.

What is different when relaunching a strategy?

You have defined a variable as class level. Search for "class level variable C#" in Google or browse any C# 101 book.

I have googled what you suggested and have to ask now: What's wrong with class level variables? They are widely used.

I have a lot of variables that I refer to in 'MyStrategy()' and in 'Execute()' as well. That's why I have declared them as class level variables.

My 'bars' and 'series' variables, however are not class level variables.


In this case,

CODE:
Please log in to see this code.

bars[] is not a class level variable, but input.Field is a class level variable, which always contains the correct value.


So where exactly is the problem ?

There's nothing wrong with class level variables, they're very helpful at times (example).

A class level variable will not be reset when you click Go - unlike when recompiling a Strategy with Execute().

I know that and I take this into account. But now, where is the problem?

My variables are filled, whether class level or not, with the same contents whether I run it for the first time or with 'Go'.

I don't understand what this discussion has to do with the problem at hand.

You asked:

QUOTE:
What is different when relaunching a strategy?

I answered.

QUOTE:
I don't understand what this discussion has to do with the problem at hand.

Try replacing your Bloomberg DataSeries with e.g. Yahoo DataSeries. If there's no difference, the culprit is somewhere in your code.

I have only Bloomberg Data Series, nothing else, and all work well, except the described case of special Bloomberg fields. I don't think it's somewhere in my code because I can step through the program and inspect the parameters for

CODE:
Please log in to see this code.

So if 'bars' and 'field' are confirmed to be correct, what else could cause 'ds' to be all zeroes the second time around ?

Without telepathic abilities and crystal ball, I can't inspect your code and access your data. At the same time, my experience won't let me blindly trust your thinking that your code is OK just because you think so. ;)

So, at the risk of repeating, my only suggestion at this point is: take the BB provider out of the equation. Replace your Bloomberg Named DataSeries with the OHLC DataSeries by any other provider, preferably Yahoo.

If it worked, there's something about the BB provider. If it didn't work, there is something in your code - like a class-level variable, for example, or something else that we're unlikely to guess from here unless you handicap us by providing a "cleaned up", short version of your Strategy. Substitute some generics for key buy/sell decision to get a top view sanity check. Note that the trading logic and/or its interaction with the rest of the Strategy may be related to where the actual problem lies.

All my strategies run through the same code and only a few of them require special Bloomberg Data like

BE500;INDX_ADV_VOL.WLC

The basic data files are all .WL files and I hope it makes no difference from where a .WL file has been loadedinitially. Example

BE500.WL

I have never had problems with the .WL files, only with the .WLC files.

Following your reasoning there must be something about the 'BB provider', enabled by using WealthLab.DataProviders.Blmbrg;

But I am at a loss here.

I'm at a loss why the idea of taking the BlmbrgF.Series (Bloomberg static provider) out of the equation for debugging purposes faces such a strong opposition. Without cooperation from you on 1) circumventing the BB provider and 2) providing short example code to demonstrate the effect, there's not much we can do at this point. It's your code and we can't see it.

Do you see any problem when running a simple example like this one? Replace the fields with the ones you're using.

CODE:
Please log in to see this code.

If not, please create a simple example like this that demonstrates the problem.

I know I need to setup a such a small strategy in order to show problems that I have. I will do this as soon as I get a chance. Thank You!

For the past year or so I have implemented a workaround for this problem. Now it was necessary to tackle it again. This time I was able to nail it down:

CODE:
Please log in to see this code.

In this sequence, statement 1 and 2 are identical to statment 4 and 5. However, not the output. After the 2nd statement, testSeries1 is correctly filled with the data from the Bloomberg field. After execution of statement 5, testSeries1 is empty (all zeroes)!

If the statement 3 refers to the same DataSet as statement 1 and 4, the condition does not hold (i.e. testSeries1 is correct after execution of the 5th statement).

It seems that the request of a ticker of another DataSet somehow disables the ability of the BlmbrgF.Series function to get the Bloomberg data in the first DataSet anymore.

After the creation testSeries1, BlmbrgF(INDX_ADV_VOL) is cached in Bars testBars1. I don't immediately understand why the process wouldn't work the second time around (bug), but...

1. There should be no need to re-assign GetExternalSymbol to testBars1 a second time. Why would you do that? (other than for the sake of this example)

2. Likewise, there shouldn't be a need to re-assign the fundamental series to testSeries1 either. These Bars and DataSeries variables already contain the result you need.

3. If you use testSeries1 in a loop, assigning different series values to the same variable as you need it, it should be sufficient to call statement 5 without using statement 4 again since the indicator result is already cached. If you comment out statement 4, it works correctly, right?

Thank you for your answer.

as to 1: Of course it is only for the sake of this example. In reality, I only have statements 3 to 5. As I mentioned earlier in this thread, the problem arises when Execute() is called for the second time. This could be the case for instance when the start and/or end dates are changed and 'Go' is pressed in WL6.

as to 2: In the case described above, it is necessary that testSeries1 is assigned again.

as to 3: yes

QUOTE:
As I mentioned earlier in this thread, the problem arises when Execute() is called for the second time. This could be the case for instance when the start and/or end dates are changed and 'Go' is pressed in WL6.

Do you use class level variables?

Yes, but the condition holds in any case.

Unfortunately I cannot duplicate the scenario. Do the "1_EqIdx" and "3_G_Bonds" directories reside on the same machine? If multiple drives / or network is involved, how is it set up?

Now this is interesting.I don't believe that our setup could be the culprit.

1_EqIdx and 3_G_Bonds reside on the same network drive, mapped to X:

It is a normal Microsoft Server 2008 network where all PC's and the server are connected to a Router. So nothing special there.

I have attached some screenshots where you can see how the Bloomberg data disappears after pressing 'Go'.

I believe that this might have to do with your use of class level variables.

I think I have ruled that out but I will do it again. I will declare all Bars and DataSeries variables local and make the same test.

Now I have moved all my 'Bars' and 'DataSeries' objects to the 'Execute()' method:

CODE:
Please log in to see this code.

maxSeries however is a class level variable, but I cannot imagine that this would have any influence.

What ticker and Bloomberg field dit you use in order to duplicate the scenario? I will then use the same and see if it makes a difference.

I used PE_RATIO, but this won't matter. The data for fundamental items are all stored and synchronized the same way. Anyway, I certainly understand the possibility for the failure condition to occur, that's why there's a specific order of using BlmbrgF.Series after SetContext() or GetExternalSymbol().

I'll set up my [very limited] bb data on a network drive and see if makes a difference in the test.

This still works for me even with the mapped drive.

The only thing I can suggest is that you create a Support Ticket, zip up your data, and attach it to the ticket. It will be sufficient to have just the data files required by the script.