Warum verwalten zwei Gold-EAs denselben Auftrag? MT4-Magic-Nummer prüfen

Autor: Thomas｜MT4-Praxis｜10. November 2026

Zusammenfassung: Wenn in einem MT4-Konto zwei Gold-EAs laufen und dieselben Kriterien zur Auftragserkennung verwenden, können sie gleichzeitig den Stop-Loss eines Auftrags ändern. Bei der Fehlersuche prüft man zuerst Symbol und Magic-Nummer des Auftrags und dann, nach welchen Bedingungen der Code tatsächlich filtert. Die folgenden Nummern und Aufträge sind didaktische Annahmen.

Wo die Magic-Nummer gespeichert wird

OrderSend in MQL4 unterstützt die Übergabe des magic-Parameters. Nachdem ein Auftrag erfolgreich ausgewählt wurde, kann OrderMagicNumber die Kennnummer dieses Auftrags auslesen. Sie kann dem Programm eine Grundlage zur Klassifizierung geben. Welche Aufträge tatsächlich geändert oder geschlossen werden, hängt weiterhin von der Filter- und Ausführungslogik des EA selbst ab. Wenn das Programm beim Durchlaufen der Kontoaufträge nur das Symbol prüft, können zwei Gold-EAs selbst dann dieselbe Auftragsgruppe bearbeiten, wenn sie unterschiedliche Magic-Nummern eingetragen haben.


Im Diagramm wird angenommen, dass Strategie A und B die Nummern 101 bzw. 202 verwenden. A wählt Aufträge im Handelspool einzeln aus, prüft zuerst das tatsächliche Symbol und dann die Kennnummer. Erst wenn beide Kriterien passen, wird der Auftrag an die nachfolgende Logik zur Prüfung von Auftragstyp und erlaubten Aktionen übergeben. Schlägt die Auftragsauswahl fehl, sollte sie übersprungen und der Fehler protokolliert werden. Vor Änderungen sollte der Zielauftrag erneut ausgewählt werden, um die Verwendung zuvor in das Programm kopierter alter Daten zu vermeiden.

In drei Schritten mit einem Demokonto verifizieren

Schritt eins: Version, Eingabeparameter, Chartzeitrahmen und vollständigen Symbolnamen des Brokers für beide EAs dokumentieren. Der Goldname kann je nach Konto einen Suffix haben. Wenn mehrere Instanzen für dasselbe Symbol eingesetzt werden, muss außerdem klar sein, ob sie Aufträge unabhängig verwalten oder konstruktionsbedingt gemeinsam nutzen.

Schritt zwei: Im Demokonto jede EA einen erkennbaren Testauftrag erzeugen lassen und zugleich einen Testauftrag vorbereiten, der ausgeschlossen werden soll. Im Log mindestens Auftragsnummer, Symbol, Magic-Nummer und die vom Programm geplante Aktion festhalten. Dann eine kontrollierte Verwaltungsaktion auslösen, beispielsweise versuchen, den eigenen Testauftrag von Strategie A zu ändern, und prüfen, ob der Auftrag von Strategie B unverändert bleibt. Schwebende Orders und bereits ausgeführte Positionen sollten möglichst getrennt geprüft werden, da der Handelspool beide Arten enthalten kann und die tatsächlichen Verarbeitungsregeln üblicherweise unterschiedlich sind.

Schritt drei: Nach einem Neustart des Terminals oder erneutem Laden des EA noch einmal prüfen. Wenn das Programm nur die während des aktuellen Laufs angelegte Auftragsliste speichert, kann sich das Verhalten nach einem Neustart ändern. Prüfen, ob es Aufträge nach den festgelegten Bedingungen erneut erkennt und ob bei fehlenden passenden Aufträgen unerwartete Aktionen auftreten. Nummern dienen nur der unterstützenden Isolation; wenn eine kontoweite Gesamtrisikoprüfung bewusst alle Positionen liest, sollte dies getrennt von der Berechtigung zur tatsächlichen Auftragsänderung dokumentiert werden.

Vor dem Wechsel der Nummer zuerst alte Aufträge behandeln

Angenommen, Strategie A hat zuvor mit 101 Positionen eröffnet und wird nun auf 303 geändert. Änderungen der Eingabeparameter wirken üblicherweise nur auf die Werte, die der nachfolgende Code verwendet; die Kennnummer alter Aufträge wird nicht automatisch mit den Chart-Einstellungen migriert. Wenn die Verwaltungsbedingung nur auf 303 passt, können ursprüngliche 101-Aufträge übersprungen werden. Vor der Änderung sollten alte Aufträge und die geplante Behandlung aufgelistet und anschließend Neustart und Übergabe in einer Demoumgebung verifiziert werden. Bei EAs, deren Version nicht nachvollziehbar ist oder deren Log die Filterlogik nicht erklärt, sollte die automatische Verwaltungsänderung zunächst pausiert und die Exit-Regelung bestehender Positionen geprüft werden. Ein bestandener Demotest belegt nur das getestete Szenario; reale Kursänderungen, Server-Ablehnungen und Slippage müssen weiterhin separat bewertet werden.