Fehler, Irrtümer, Fragen - Seite 1221

 
Fry:

Fehler

Herausforderung:


Führt zu einer Meldung im Logbuch:

HistoryBase 'RTS-12.14' 1 ungültige Balken entfernt


Ich habe die Nase voll von diesem Fehler. Unter anderem wird damit auch der Kommunikationskanal belastet.

Derselbe Fehler tritt aus anderen, nicht identifizierten Gründen auf.

Interessanterweise taucht sie aber bei vielen anderen Instrumenten nicht auf. Sie erscheint am häufigsten in den RTS-Futures.


Ich habe vor ein paar Monaten an servicedesk geschrieben - keine Antwort(Anfrage gestartet: 2014.07.28 13:41, #1046215).


Ich hänge den Code des Induke an, der diesen Fehler bei jedem Tick der aktuellen (und vergangenen) RTS-Futures verursacht (Demokonto mit Broker "O..."):

Ist dies ein Fehler im Terminal? Oder beim Makler? Oder ich?

Was sollte ich tun? Wie kann man sonst die Anzahl der Balken auf dem D1-Zeitrahmen ermitteln?

Guten Abend. Haben Sie es ausprobiert?

SeriesInfoInteger( _Symbol, PERIOD_D1, SERIES_BARS_COUNT );
 
Tapochun:

Guten Abend. Haben Sie das schon ausprobiert?

Ihnen auch einen guten Abend. Ich habe es ausprobiert, es ist alles dasselbe.

Das Ergebnis ist das gleiche. Der Fehler wird für jeden Tick in das Protokoll aufgenommen.

Ich danke Ihnen für diese Idee. Wenn SeriesInfoInteger() intern nicht Bars aufruft, ist es wahrscheinlicher, dass es sich um eine "schmale" Datenpanne auf dem Broker-Server handelt.

Und das ist auch eine zufriedenstellende Antwort auf meine Frage.

Es ist ja nicht so, dass ich nicht wüsste, wo der Fehler auftauchen wird, ob ich ihn vermeiden kann, usw.

 
Fry:

Auch Ihnen einen guten Abend. Ausprobiert - das Gleiche.

Das Ergebnis ist das gleiche. Der Fehler wird für jeden Tick in das Protokoll aufgenommen.

Ich danke Ihnen für diese Idee. Wenn SeriesInfoInteger() nicht intern auf Bars zugreift, ist es immer wahrscheinlicher, dass es sich um eine "enge" Datenverbindung auf dem Server des Brokers handelt.

Und auch das ist eine zufriedenstellende Antwort auf meine Frage.

Schließlich weiß ich nicht, wo der Fehler auftauchen wird, ob ich ihn vermeiden kann, usw.

Vielleicht liegt wirklich ein Fehler beim Broker vor, denn die Meldung löscht einige "kaputte" Balken... oder die Daten werden auf dem Weg "getötet". Aber das ist nur eine Vermutung meinerseits. Gibt GetLastError() übrigens etwas her? Ja, und was gibt Bars() zurück?
 
Tapochun:
Wahrscheinlich handelt es sich tatsächlich um einen Fehler des Brokers, denn die Meldung löscht einige "kaputte" Balken... oder die Daten werden auf dem Weg "getötet". Aber das ist nur eine Vermutung meinerseits. Gibt GetLastError() übrigens etwas her? Ja, und was gibt Bars() zurück?

Wenn Bars() 0 zurückgibt, tritt der Fehler 4001 (ERR_INTERNAL_ERROR 4001 Unerwarteter interner Fehler) auf.

Aber manchmal gibt Bars() immer noch die Anzahl der Balken zurück, und dann gibt es keinen Fehler (Bars() ändert den Fehlerstatus nicht).

 

MT4 Build 722, ME4 Build 989

Es wird versucht, die aktuellen Daten des Nullbalkens zu kopieren:

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

Druckt n=0, d.h. die Daten werden nicht kopiert.

Wenn_Period anstelle vonPERIOD_CURRENT geschrieben wird, funktioniert es.

Wenn Sie Taktdaten , die nicht Null sind (time[1] usw.), kopieren, funktioniert es, unabhängig davon, ob SiePERIOD_CURRENT oder_Period schreiben.

P.S. Möchten Sie es auf einer CD haben?

 
Fry:

Wenn Bars() 0 zurückgibt, tritt der Fehler 4001 (ERR_INTERNAL_ERROR 4001 Unerwarteter interner Fehler) auf.

Aber manchmal gibt Bars() immer noch die Anzahl der Balken zurück und dann gibt es keinen Fehler (Bars() ändert den Fehlerstatus nicht).

Die "Unerwartetheit" des Fehlers deutet wiederum darauf hin, dass etwas nicht rechtzeitig ankommt und gelöscht wird, woraufhin der Fehler auftritt. Soweit ich verstehe, müssen Sie die Anzahl der Balken auf D1 herausfinden... Müssen Sie das bei jedem Tick tun? Alternativ können Sie eine Funktion schreiben, die einmal pro Minute oder weniger Daten anfordert. Und schauen Sie, ob ein Fehler auftritt.

 
kPVT:

MT4 Build 722, ME4 Build 989

Es wird versucht, die aktuellen Daten des Nullbalkens zu kopieren:

Druckt n=0, d.h. die Daten werden nicht kopiert.

Wenn_Period anstelle vonPERIOD_CURRENT geschrieben wird, funktioniert es.

Wenn Sie Taktdaten , die nicht Null sind (time[1] usw.), kopieren, funktioniert es, unabhängig davon, ob SiePERIOD_CURRENT oder_Period schreiben.

P.S. Möchten Sie es auf einer CD haben?

Abend. Versuchen Sie es... obwohl, wenn es eine Alternative gibt, ist es unwahrscheinlich, dass sie sich auf die Suche nach dieser Schwachstelle begeben. Ich habe jetzt seit einer Woche zwei Bewerbungen in der Schublade... keine Antwort, kein Wort.
 
Fry:

Was ist zu tun? Wie kann ich sonst die Anzahl der Balken auf dem D1-Zeitrahmen ermitteln?

Läuft der Indikator auf D1?
 
MigVRN:
Läuft der Indikator auf D1?

Nein, natürlich nicht. Das ist der springende Punkt. Wenn der Indikator selbst auf D1 läuft, haben wir trivialerweise"constint rates_total, // size of input timeseries".

Hier ein konkretes Beispiel für seine Verwendung.

Wir haben ein paar Indikatoren initialisiert und ihre Handles erhalten (hier ist alles in Ordnung). Als nächstes müssen wir in der ontik-Funktion sicherstellen, dass zum Zeitpunkt des Aufrufs alle Daten auf den erforderlichen Handles (externe Indizes) berechnet worden sind. Und das ist es, was ich tue:

   //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);

Und in diesem Fall ist hDayTrand ein rekursiver Handle (derselbe Indikator, nur D1 wird geladen).

Ich scheine alles gemäß der Dokumentation und den Beispielen aus dem Terminal und den Empfehlungen zu tun. Das Ergebnis ist, dass all diese Dinge im Protokoll verschlüsselt werden und Megabytes pro Minute verschlingen.

 
Fry:

Nein, natürlich nicht. Das ist der springende Punkt. Wenn der Indikator selbst auf D1 läuft, haben wir trivialerweise"constint rates_total, // size of input timeseries".

Hier ein konkretes Beispiel für seine Verwendung.

Wir haben ein paar Indikatoren initialisiert und ihre Handles erhalten (hier ist alles in Ordnung). Als nächstes müssen wir in der Ontik-Funktion sicherstellen, dass zum Zeitpunkt des Aufrufs alle Daten zu den benötigten Handles (externe Indizes) bereits berechnet wurden. Und das ist es, was ich tue:

Und in diesem Fall ist hDayTrand ein rekursiver Handle (derselbe Indikator, nur D1 wird geladen).

Ich scheine alles gemäß der Dokumentation und den Beispielen aus dem Terminal und den Empfehlungen zu tun. Das Ergebnis: All diese Dinge werden in das Protokoll gekritzelt und fressen Megabytes pro Minute.

IMHO, müssen Sie den Makler (Otkrytie, so verstehe ich) zu kontaktieren. Die echten Konten haben es nicht, also liegt es wahrscheinlich an den Servereinstellungen.