You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Faced with bug when CopyTicksRange returns all requested ticks correctly, but with LastError == ERR_HISTORY_TIMEOUT(4403).
It's not a bug, it's a feature. It's the same with CopyTicks, sometimes. I haven't figured out how to use this "thing" yet.
in the description of the CopyTicksRange function:
ERR_HISTORY_TIMEOUT – время ожидание синхронизации тиков вышло, функция отдала всё что было.
Of course, I would like the developers to explain what this error means when a tick is received with the CopyTicks function. How to handle this error. ps: I call it in an indicator
Please advise what data needs to be provided to solve this problem as soon as possible?
Tiki is not copying, giving an error.
Constant
Value
Description
ERR_HISTORY_SMALL_BUFFER
4407
Receiving array too small to hold all requested data
It's impossible to work properly with such surprises!
Through the GUI (CTRL+U) the ticks are taken without any problems.
Search string: Oshibka 007.Please advise what data needs to be provided to solve this problem as soon as possible?
Tiki is not copying, giving an error.
Constant
Value
Description
ERR_HISTORY_SMALL_BUFFER
4407
Receiving array too small to hold all requested data
Tested locally in various ways - so far no playback. Need more details:
1. What version of the terminal?
2. What server are you working with?
3. On which character is the script called?
4. If not called with COPY_TICKS_INFO but with COPY_TICKS_ALL is the error ERR_HISTORY_SMALL_BUFFER also set?
Thank you!
Tested locally in various ways - so far no playback. Need details:
1. What version of the terminal?
2. What server are you working with?
3. On which character is the script called?
4. If you do not call it with COPY_TICKS_INFO but with COPY_TICKS_ALL will the error ERR_HISTORY_SMALL_BUFFER also be raised?
Thank you!
ZS In the trailer is custom. Create symbol from json, import ticks, run script on this symbol's chart. Please write whether or not it reproduced.
Please write whether it played or not.
Yes, it played back on 2380.
Thank you very much! Sorting it out.
ZY The trailer is custom. Create symbol from json, import ticks, run script on this symbol's chart. Please write whether it reproduced or not.
Thanks again.
Yes, in 2380 the problem was accidentally introduced and then it was quickly fixed. But it managed to get into build 2380.
Unfortunately since then new builds where all fixed on MetaQuotes-Demo was not yet.
You can either roll back to any previous build or wait for the next build on MetaQuotes-Demo.You can either roll back to any previous build or wait for the next build on MetaQuotes-Demo.
Thanks, for now the previous build is for real. The 2380 has done a lot...
MT5 latest release build 2361. Attached is a custom symbol. Create a symbol from json, import ticks, run a test on the chart of this symbol.
EA
Parameters
1. Netting account.
1.1. With the given dates the output is similar to true: 2000 0 2000 0.
1.2. When the dates are changed to 07.04.2020-08.04.2020 the output becomes strange: -1 4004 1 0.
Firstly, why does the error appear in the first case? Secondly, why does the second case take only 1 tick? The date of the tick request has not changed.
2. Hedge account.
2.1. With the given dates the output becomes strange: 2000 0 1 0.
Why does the second case only take 1 tick? The date of the tick request has not changed.
2.2. When the dates changed to 07.04.2020-08.04.2020 the output will stop strange, but the same: 2000 0 1 0.
Hence questions: why CopyTicks with fixed parameters depends not only on test dates, but also on account type? Or I don't understand something and I'm doing something wrong?
This makes it very difficult to work, please correct if possible. Have you managed to reproduce it? Anything else you need from me to reproduce? Thank you.
Hence the questions: why does CopyTicks with fixed parameters depend not only on test dates, but also on account type? Or am I misunderstanding something and doing something wrong?
Dependence on account type - you can roughly imagine the reasons. I would not say it is correct. Exchange symbols with last history - the developers need to think well once there, what to do with them on the hedge, etc.
I don't use CopyTicks myself in Tester. The first 24 hours are not important. If you really need clear trading signals, then do not trade the first day.
MT5 latest release build 2361. Attached is a custom symbol. Create a symbol from json, import ticks, run the EA on a chart of this symbol.
EA
Parameters
1. Netting account.
1.1. With the given dates the output is similar to true: 2000 0 2000 0.
1.2. When the dates are changed to 07.04.2020-08.04.2020 the output becomes strange: -1 4004 1 0.
Firstly, why does the error appear in the first case? Secondly, why does the second case take only 1 tick? The date of the tick request has not changed.
2. Hedge account.
2.1. With the given dates the output becomes strange: 2000 0 1 0.
Why does the second case only take 1 tick? The date of the tick request has not changed.
2.2. When dates change to 07.04.2020-08.04.2020 the output will stop strange, but the same: 2000 0 1 0.
Hence questions: why CopyTicks with fixed parameters depends not only on test dates, but also on account type? Or I don't understand something and I'm doing something wrong?
This makes it very difficult to work, please correct if possible. Have you managed to reproduce it? Anything else you need from me to reproduce? Thank you.
The very first run. Looking at the tester logs.
The tester synchronised the ticks for just one day, for 8 April. That is, there are no ticks before April 8.
At the beginning we got error 4004 (not enough memory for the requested ticks). This is an invalid message, we'll look into it. It seems to be because the request with default parameters is on the boundary of existing ticks
The next query quite rightly gave you 1 tick. Because from 2020.04.06 00:00:00 until the current tester, when the first tick arrived, there is only one existing tick.
Let's adjust the EA a little bit
and we see, that from the second tick, the ticks have started to be picked up. In both cases it is 2 ticks.
That is, the assumption of the request error at the tick boundary has proven to be correct.
Let's change the start date to April 7.
All the same, except for the fact that the ticks are synchronized for 2 days already - the tester database contains ticks for April 7 and 8.
We set the start date back to April 8. And we see the expected result
Because there are more ticks in the tester than in the very first run. And it has nothing to do with hedging and netting.