OnTradeTransaction - page 9
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Oui, vous avez raison, car dans ce cas, il s'agit d'un identifiant de position, constant tout au long de sa vie. Je l'ai confondu avec le ticket de la position, qui change lors des rollovers et du netting.
Mais je ne comprends pas - quand une position est partiellement fermée, le ticket ne devient pas le ticket du dernier ordre affectant la position ?
Je vais revoir mes codes, merci. Je n'ai pas visité le forum pour rien)
Concernant la "commande perdue" qui n'est pas dans la liste des commandes actuelles ou historiques : Il me semble que ce n'est pas un bug, il faut juste que je regarde attentivement les fonctionnalités de
Je pense que ce n'est pas un bug, il faut juste examiner attentivement les particularités du terminal-serveur MT-market (dans le cas d'une exécution instantanée, le marché ne fonctionne pas). Je pense que oui, regardez - le terminal envoie un ordre de marché, dans le cas de la fonction synchrone - il attend et reçoit une réponse du serveur,
S'il n'y a pas d'erreur, la réponse ne peut être que TRADE_RETCODE_DONE (dans le cas d'une exécution instantanée, il s'agit de requotes, mais jusqu'à présent, c'est le type de marché), ce qui signifie essentiellement que le serveur a envoyé l'ordre au marché et que celui-ci
Cela signifie en fait que le serveur a envoyé l'ordre et attend sa réponse. L'état de la commande à ce moment estORDER_STATE_STARTED si je ne me trompe pas et son ticket est connu. Si l'ordre est exécuté, le serveur envoie OnTradeTransaction au terminal et le statut de l'ordre passe à ORDER_STATE_FILLED et la transaction est connue.
et la position devient connue. C'est seulement à ce moment que le terminal enregistre la commande dans l'historique. Il ne le fait pas au préalable car nous ne savons pas ce qui lui est arrivé et il a déjà donné la réponse initiale du serveur.
C'est le temps jusqu'à ce que l'ordre soit exécuté dans le réseau ECN ou ailleurs, ils ne sont dans aucune des deux listes. C'est-à-dire que dans le cas d'un ordre au marché, il n'apparaît que dans l'historique (je ne suis pas sûr du cas des requêtes lors de l'exécution instantanée),
il n'apparaîtra jamais dans la liste de ceux qui sont ouverts. Et quand un ordre en attente se déclenche, il est retiré de la liste des ordres ouverts parce qu'il est déjà devenu un ordre de marché et nous attendons que le serveur de marché réponde, puis il est envoyé à l'historique.
Ai-je raison ?
Ai-je raison ?
Andrey l'a très bien expliqué.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
OnTradeTransaction
Andrey Khatimlianskii, 2019.12.17 08:24
Non, les choses sont pires.
Au moment de la transformation de l'ordre en attente (ou marché) en ordre historique (exécuté ou annulé), pendant un certain temps, l'ordre disparaît complètement du terminal. Il n'apparaît ni parmi les marchés en cours (ou "commencés"), ni parmi les marchés historiques.
Il ne s'agit donc pas d'une question d'exécution, mais de synchronisation de ces deux tables. La réponse du serveur est arrivée ("Ordre exécuté, a généré la transaction untel"), elle est retirée d'une table, mais pas entrée dans l'autre.
Le problème ne vient pas de OrderSend. Il y a eu BuyLimit pendant longtemps. Et soudain, elle et les positions d'achat sont introuvables. C'est à peu près la même situation qui se produit.
Andrei l'a bien écrit.
Il ne s'agit pas d'OrderSend. C'était BuyLimit pendant longtemps. Et soudain, ni elle ni la position d'achat ne se trouvent nulle part. C'est à peu près la même situation qui se produit.
Pas vraiment.
J'ai compris. Même l'ordre au prix du marché figure dans la liste des ordres en cours depuis un certain temps (mais il semble qu'il ne s'affiche pas dans le terminal dans l'onglet "trade").
Puis, lorsque la commande a été exécutée et qu'une transaction correspondante a été reçue du serveur, le terminal effectue les actions suivantes
1. supprimer l'ordre de l'actuel
2. écrire la commande en historique
3. écrire le métier à la liste
4. écrire la position dans la liste
et compte tenu du fait que le conseiller expert et le terminal lui-même travaillent dans des flux parallèles indépendants, le terminal ne sera pas encore en mesure d'ouvrir une position si vous le demandez dans ce court laps de temps.
position, il ne sera pas encore là. Comme je l'ai déjà écrit, si cela se passait selon les normes des SGBD, il n'y aurait rien de tel, car les 4 opérations seraient combinées en une seule transaction, et on ne pourrait pas se retrouver dans des "états intermédiaires".
N'est-ce pas ? Mais je suis en fait intéressé - si nous nous appuyons sur OnTrade et OnTradeTransaction, alors il ne devrait pas y avoir de décalage dans ces gestionnaires, ils se produisent en créant des changements dans les tables correspondantes, non ?
Ou bien le terminal les envoie simplement au conseiller expert lorsqu'il reçoit des événements et modifie les tableaux en même temps ? Dans ce dernier cas, elle est bien sûr erronée et doit être corrigée, surtout si le système OnTradeTransaction, à partir duquel les informations réelles pourraient être obtenues, n'est pas garanti.
Je l'ai. Même l'ordre au prix du marché est présent dans la liste des ordres en cours depuis un certain temps (seulement il semble qu'il ne soit pas affiché dans l'onglet de négociation dans le terminal ?)
Parfois, vous pouvez même le voir de vos yeux lorsqu'il est en état de démarrage. Et c'est facile à suivre avec un robot.
Et compte tenu du fait que le conseiller expert et le terminal lui-même fonctionnent dans des flux parallèles indépendants, la situation est la suivante : si vous demandez une position dans ce court laps de temps, elle n'apparaîtra pas.
Nous ne faisons pas référence aux positions mais uniquement aux ordres.
Nous avons besoin de beaucoup moins de temps pour ajouter une entrée au tableau que ce que nous obtenons parfois. Et nous ne sommes pas sérieux, il n'y a aucune garantie que nous obtiendrons le bon environnement commercial.
Et je me demandais en fait - si nous nous appuyons sur OnTrade et OnTradeTransaction, alors ces gestionnaires ne devraient pas avoir de retard, parce qu'ils se produisent lorsque les changements sont écrits dans les tables appropriées ?
Ou bien le terminal les envoie simplement au conseiller expert lorsqu'il reçoit des événements et modifie les tableaux en même temps ? Dans ce dernier cas, il est bien sûr faux et doit être corrigé, surtout si OnTradeTransaction, à partir duquel vous pourriez obtenir des informations réelles, n'est pas garanti.
OnTrade dans sa forme pure ne vous aidera pas.
Vous pouvez également y associer la synchronisation de la table d'attente des commandes, c'est une question de goût. Mais vous devez encore attendre.
En ce qui concerne "l'ordre perdu", qui n'est pas dans la liste des ordres actuels ou historiques : je pense que ce n'est pas un bug, il faut juste regarder de près les caractéristiques du Terminal-Serveur MT-Market (dans le cas de l'exécution instantanée le marché est out). Je pense que le terminal envoie un ordre de marché, dans le cas d'une fonction synchrone il attend et reçoit une réponse du serveur. S'il n'y a pas d'erreur la réponse peut seulement être TRADE_RETCODE_DONE (dans le cas d'une exécution instantanée il y a des requotes, mais jusqu'à présent c'est l'ordre de marché) ce qui signifie en fait que le serveur a envoyé l'ordre au marché et attend une réponse. L'état de la commande à ce moment est ORDER_STATE_STARTED si je ne me trompe pas et son ticket est connu. Si l'ordre est exécuté, le serveur envoie OnTradeTransaction au terminal et le statut de l'ordre passe à ORDER_STATE_FILLED et la transaction et la position sont connues. C'est seulement à ce moment que le terminal enregistre la commande dans l'historique.
Le marché n'a rien à voir avec cela.
Le serveur MetaTrader envoie l'ordre à ECN ou ailleurs, obtient la réponse et l'envoie au terminal. Et dans le terminal, le timing n'est pas bon.