Errors, bugs, questions - page 1221

New comment
 
Fry:

Error

Challenge:


Leads to a message in the logbook:

HistoryBase 'RTS-12.14' 1 invalid bars removed


I'm fed up with this error. Amongst other things, it's also loading up the communication channel.

The same error appears for other, unidentified reasons.

But, interestingly, it doesn't appear on many other instruments. It appears the most on the RTS futures.


I wrote to servicedesk a few months ago - no reply(Request started: 2014.07.28 13:41, #1046215).


I am attaching the code of the induke that causes this error on every tick of the current (and past) RTS futures (demo account with broker "O..."):

Is this a bug in the terminal? Or at the broker? Or me?

What should I do? How to know the number of bars on D1 timeframe otherwise?

Good evening. Have you tried it?

SeriesInfoInteger( _Symbol, PERIOD_D1, SERIES_BARS_COUNT );
 
Tapochun:

Good evening. Have you tried this?

Good evening to you, too. I've tried it. It's all the same.

The result is the same. The error is in the log for every tick.

Thank you for the idea. If SeriesInfoInteger() is not accessing Bars internally, then everything is more likely that it is a "narrow" data screw-up on the broker server.

And that is also a satisfactory answer to my question.

After all, it's not like I don't know where the error is going to pop up, whether I can avoid it, etc.

 
Fry:

Good evening to you too. Tried it - same thing.

The result is the same. The error is in the log for every tick.

Thank you for the idea. If SeriesInfoInteger() is not accessing Bars internally, then it is more and more probable that it is a "narrow" data joint on broker's server.

And that too is a satisfactory answer to my question.

After all, I don't know where the error is going to pop up, whether I can avoid it, etc.

Perhaps there really is an error at the broker, as the message deletes some "broken" bars... or the data gets "killed" along the way. But, this is just a guess on my part. By the way, does GetLastError() give me anything? Yes, and what does Bars() return?
 
Tapochun:
Probably, broker's error indeed, because the message deletes some "broken" bars... or the data gets "killed" on the way. But, this is just a guess on my part. By the way, does GetLastError() give me anything? Yes, and what does Bars() return?

If Bars() returns 0, then error 4001 (ERR_INTERNAL_ERROR 4001 Unexpected internal error).

But sometimes Bars() still returns number of bars and then there is no error (Bars() does not change error status).

 

MT4 build 722, ME4 build 989

Trying to copy current zero bar data:

      MqlRates rates[1];
      int n=CopyRates(_Symbol,PERIOD_CURRENT,time[0],1,rates); 
      Print("n=",n);

Prints n=0 i.e. data is not copied.

If_Periodis written instead ofPERIOD_CURRENT , it works.

If you copy nonzero bar data (time[1], etc.), it will work, regardless of whether you writePERIOD_CURRENT or_Period.

P.S. Do you want it in a cd?

 
Fry:

If Bars() returns 0, then error 4001 (ERR_INTERNAL_ERROR 4001 Unexpected internal error).

But sometimes Bars() still returns number of bars and then there is no error (Bars() does not change error status).

The "unexpectedness" of the error once again suggests that something does not have time to reach and is deleted, as a result of which the error occurs. As far as I understand, you need to find out the number of bars on D1... Do you have to do it on every tick? Alternatively, write a function that will request data once a minute or less. And see if an error occurs.

 
kPVT:

MT4 build 722, ME4 build 989

Trying to copy current zero bar data:

Prints n=0 i.e. data is not copied.

If_Periodis written instead ofPERIOD_CURRENT , it works.

If you copy nonzero bar data (time[1], etc.), it will work, regardless of whether you writePERIOD_CURRENT or_Period.

P.S. Do you want it in a cd?

Evening. Try it... although if there's an alternative, they're unlikely to rush to look for this flaw. I've had two applications hanging around for a week now... no answer, no word.
 
Fry:

What to do? How else do I know the number of bars on the D1 timeframe?

Is the indicator running on D1?
 
MigVRN:
Is the indicator running on D1?

No, of course not. That is the whole point. For when the indicator itself is running on D1, we trivially have"constint rates_total, // size of input timeseries".

Here is a concrete example of its use.

We initialized a couple of indicators and got their handles (everything is OK here). Next, in the ontik function we need to make sure that at the time of the call all data has been calculated on the required handles (external indices). And this is what I do:

   //not all data may be calculated
   if (BarsCalculated(hCCI)<rates_total) {Print("Not all data of trend CCI is calculated. Error#",GetLastError()); return(0);}
   if (Period()!=PERIOD_D1 && BarsCalculated(hDayTrand)<Bars(Symbol(),PERIOD_D1)) return(0);

And in this case hDayTrand is a recursive handle (the same indicator, only D1 is loaded).

I seem to do everything according to documentation and examples from the terminal and to recommendations. The result is that all this stuff is scrambled in the log and eats megabytes per minute.

 
Fry:

No, of course not. This is the whole point. For when the indicator itself is running on D1, we trivially have"constint rates_total, // size of input timeseries".

Here is a concrete example of its use.

We initialized a couple of indicators and got their handles (everything is OK here). Next, in the ontik function we must make sure that at the moment of the call all data on the required handles (external indices) has been already calculated. And this is what I do:

And in this case hDayTrand is a recursive handle (the same indicator, only D1 is loaded).

I seem to do everything according to documentation and examples from the terminal and to recommendations. The result - all this stuff is scribbled in the log and eats megabytes per minute.

IMHO, you have to contact the broker (Otkrytie, so I understand). The real accounts don't have it, so it's in the server settings, most likely.
1...121412151216121712181219122012211222122312241225122612271228...3189
New comment
Reason: