Après lecture, je n'ai pas trouvé la meilleure réponse à cette question.
Comment charger dans le cache, par exemple, seulement 1 dernier ordre de l'historique (pour compliquer la tâche, laissez le dernier par symbole).
Par exemple, le conseiller a une fréquence d'ordres différente. Il peut passer 30 ordres par jour et peut être "silencieux" pendant plusieurs jours ou semaines.
Il existe des variantes après l'envoi d'un ordre au serveur pour mémoriser son ticket quelque part et ensuite pour récupérer cet ordre par ticket - pas de problème. Il est possible de mémoriser à la fois dans des variables globales et dans la logique de l'EA. Mais le problème se pose si, par exemple, l'Expert Advisor se connecte au compte à partir d'un autre terminal et n'a pas le ticket du dernier ordre.
Je dois charger l'historique au moyen de HistorySelect. La date de fin est plus ou moins claire, mais comment calculer la date initiale.
En effet, même dans un petit intervalle, il peut y avoir plusieurs commandes - ce n'est pas un problème, mais ce n'est pas optimal en termes de chargement de données inutiles. Il se peut aussi que l'une d'entre elles ne soit pas comprise dans la fourchette.
Il est possible de prendre une plage de dates encore plus restreinte et de faire une boucle (en déplaçant la plage dans l'historique) pour remplir le cache - ce qui n'est pas optimal en termes de logique de travail - boucles supplémentaires, requêtes dans la base de données de l'historique.
Proposition - organiser le chargement de la quantité nécessaire par commande/vente par instrument.
Et plus encore : si le but de l'article était de montrer les algorithmes optimaux d'accès aux ordres/opérations/positions. Je pense que : si nous allons plus loin en termes d'optimisation, il serait bon d'avoir un mode de chargement des données de l'historique dans le cache par champs par exemple, seuls les tickets et l'heure d'envoi de l'ordre au serveur sont nécessaires, pourquoi alors charger toutes les autres données de cette plage à ces ordres (magick, commentaire et bien d'autres).
select * from HistiryOrder where a_date_send>@datestart and a_date_send<@dateend
Pour ceux qui développent des applications SGBD, je pense qu'une telle requête ne serait pas approuvée pour une utilisation en production. Il est vrai qu'il existe des situations où toutes les données sont impliquées dans certaines actions, mais il s'agit d'une exception plutôt que d'une règle.
Après lecture, je n'ai pas trouvé la meilleure réponse à cette question.
Comment charger dans le cache, par exemple, seulement 1 dernier ordre de l'historique (pour compliquer la tâche, laissez le dernier par symbole).
Par exemple, le conseiller a une fréquence d'ordres différente. Il peut passer 30 ordres par jour et peut être "silencieux" pendant plusieurs jours ou semaines.
Il existe des variantes après l'envoi d'un ordre au serveur pour mémoriser son ticket quelque part et ensuite pour récupérer cet ordre par ticket - pas de problème. Il est possible de mémoriser à la fois dans des variables globales et à l'intérieur de la logique de l'EA. Mais le problème se pose si, par exemple, l'Expert Advisor se connecte au compte à partir d'un autre terminal et n'a pas le ticket du dernier ordre.
Je dois charger l'historique au moyen de HistorySelect. La date de fin est plus ou moins claire, mais comment calculer la date initiale.
En effet, même dans un petit intervalle, il peut y avoir plusieurs commandes - ce n'est pas un problème, mais ce n'est pas optimal en termes de chargement de données inutiles. Il se peut aussi que l'une d'entre elles ne soit pas comprise dans la fourchette.
Il est possible de prendre une plage de dates encore plus restreinte et de faire une boucle (en déplaçant la plage dans l'historique) pour remplir le cache - ce qui n'est pas optimal en termes de logique de travail - boucles supplémentaires, requêtes dans la base de données de l'historique.
Proposition - organiser le chargement de la quantité nécessaire par commande/vente par instrument.
Et plus encore : si le but de l'article était de montrer les algorithmes optimaux d'accès aux ordres/opérations/positions. Je pense que : si nous allons plus loin en termes d'optimisation, il serait bon d'avoir un mode de chargement des données de l'historique dans le cache par champs par exemple, seuls les tickets et l'heure d'envoi de l'ordre au serveur sont nécessaires, pourquoi alors charger toutes les autres données de cette plage à ces ordres (magick, commentaire et bien d'autres).
select * from HistiryOrder where a_date_send>@datestart and a_date_send<@dateend
Pour ceux qui développent des applications SGBD, je pense qu'une telle requête ne serait pas approuvée pour une utilisation en production. Il est vrai qu'il existe des situations où toutes les données sont impliquées dans certaines actions, mais il s'agit d'une exception plutôt que d'une règle.
Le chargement et le traitement d'un historique, même très important, ne prendront pas beaucoup de temps. Par ailleurs, si un tel chargement est effectué à chaque tic-tac, cela pose déjà un problème.
Même un historique très important sera traité en quelques secondes. La première conclusion est donc de réduire le nombre de chargements complets.
Commencez le chargement complet de l'historique dans OnInit(). N'oubliez pas les dates nécessaires. Ensuite, vous pouvez faire tourner l'histoire "comme une gitane avec le soleil" dans OnTicket().
Le chargement et le traitement d'un historique, même très important, ne prendront pas beaucoup de temps. Par ailleurs, si ce chargement est effectué à chaque tic-tac, il s'agit déjà d'un problème.
Même un historique très important sera traité en quelques secondes. La première conclusion est donc de réduire le nombre de chargements complets.
Commencez le chargement complet de l'historique dans OnInit(). N'oubliez pas les dates nécessaires. Ensuite, vous pouvez faire tourner l'histoire "comme une gitane avec le soleil" dans OnTicket().
Pour être plus précis, l'historique ne devrait être chargé complètement que dans le bloc d'initialisation et les week-ends (les week-ends, vous devriez également optimiser les paramètres).
Une chose m'a troublé : le texte contient de nombreux avertissements sur la nécessité de charger l'historique dans le cache avec parcimonie (de manière réfléchie), mais il n'y a pas d'exemple concret de la manière de mettre en œuvre cette tâche. Cela m'a franchement contrarié :
//--- fixer la limite initiale à 3 jours auparavant datetime start=end-3*PeriodSeconds(PERIOD_D1);
Ce code (cette approche) sera-t-il vraiment utilisé dans un Expert Advisor normal ? À moins qu'il ne s'agisse d'une tâche simple et spécifique (par exemple, trouver des ordres pour plusieurs jours), et alors - avec des réserves (dans cet exemple, les week-ends ne sont pas pris en compte, de sorte que le code n'est pas adapté au traitement de plusieurs jours de négociation ), l'approche ne résiste à aucune critique.
Pourtant, tous les outils existent pour mettre en œuvre un chargement économique. Et, en ce qui me concerne, un exemple de cette mise en œuvre devrait figurer dans l'article.
Par exemple, en utilisant ce modèle :
- OnInit() - chargement de l'historique complet dans le cache, recherche du dernier ordre significatif pour le conseiller expert (par exemple, par meijik ou simplement par instrument), sauvegarde de son temps dans une variable.
- OnTrade() - mise à jour de l'historique chargé dans le cache (à partir de l'heure mémorisée), mise à jour de l'heure du dernier ordre (si un nouvel ordre significatif est apparu).
- OnTick() - travailler avec le cache actuellement chargé ou, si nécessaire, charger le cache à partir de l'heure mémorisée.
Cette approche se caractérise déjà par sa stabilité et son universalité. En outre, en termes d'utilisation des ressources, elle peut s'avérer encore plus économique que la sélection des trois derniers jours.
Quoi qu'il en soit, merci encore pour cet article. De telles "spécifications des développeurs" sont nécessaires, sinon il n'y aura pas de code normal.
L'article donne un exemple de chargement de l'historique des transactions pour un jour (un code donne un exemple de chargement de l'historique pour 3 jours). Oui, il s'agit d'une limitation et l'exemple n'est pas universel. Mais si le lecteur comprend cette particularité en lisant l'article, il sera en mesure de décider lui-même de la question - pour quel intervalle et à partir de quel moment il doit charger l' historique des transactions dans le cache.
Le lecteur a reçu les exemples et les algorithmes les plus simples et peut maintenant les appliquer de manière autonome aux fonctions de traitement des événements nécessaires. Il peut créer sa propre base d'historique des transactions, l'initialiser, la synchroniser, etc.
Une tentative de donner des recettes et des fonctions spécifiques pour un travail optimal avec l'historique des transactions dans tous les cas nécessitera au moins un autre article. Plus précisément, il ne s'agit pas des exemples eux-mêmes, mais des approches permettant de résoudre certaines tâches. Cet article avait pour but de comprendre comment les fonctions de trading fonctionnent et quelles sont les nuances auxquelles il faut prêter attention afin de ne pas perdre son propre temps en recherches.
Je suis sûr qu'après avoir lu cet article, tout sera simple.
Pouvez-vous me dire s'il existe quelque part une description du fonctionnement du terminal en mode OfLine ? Le problème est que je n'ai pas pu charger le terminal à cause de l'absence de mise à jour des données graphiques. Je voulais le tester au travail (il n'y a pas d'internet), mais je n'ai pas pu : les graphiques attendent d'être mis à jour, et il n'y a pas un seul symbole dans le testeur. L'article dit qu'après avoir démarré le terminal, la synchronisation des données avec le serveur est effectuée. Mais que se passe-t-il s'il n'y a pas de connexion (en fait, ce n'est pas supposé être le cas) ? Il serait peut-être judicieux de dire explicitement au terminal qu'il est censé fonctionner en OfLine et de ne pas faire tourner cette malheureuse roue. Peut-être y aura-t-il moins d'échecs pour le travail du testeur. Pour être honnête, il faut dire que je n'ai pas eu ce problème depuis longtemps, mais les gens s'en plaignent sur le forum. Il y a peut-être des astuces (enfin, il y a un fichier à supprimer) pour résoudre la situation (j'ai essayé - rien n'y a fait jusqu'à ce que j'établisse une connexion avec le serveur à la maison).
- www.mql5.com
Après le transfert du catalogue du terminal vers un nouvel équipement, une partie des bases de données de configuration (symboles, paramètres de compte, historique des transactions, etc.) est spécialement supprimée parce qu'elle est cryptée par des clés câblées. L'historique des graphiques n'est pas affecté.
Cela signifie qu'après la migration, vous devez vous connecter à n'importe quel compte de trading au moins une fois pour permettre au terminal de s'adapter à l'environnement du marché. Ensuite, vous pouvez effacer le mot de passe, vous déconnecter de l'Internet et travailler avec le testeur hors ligne.
Après le transfert du catalogue du terminal vers un nouvel équipement, une partie des bases de données de configuration (symboles, paramètres de compte, historique des transactions, etc.) est spécialement supprimée parce qu'elle est cryptée par des clés câblées. L'historique des graphiques n'est pas affecté.
Cela signifie qu'après la migration, vous devez vous connecter à n'importe quel compte de trading au moins une fois pour permettre au terminal de s'adapter à l'environnement du marché. Ensuite, vous pouvez effacer le mot de passe, vous déconnecter de l'Internet et travailler avec le testeur hors ligne.
Je n'ai rien déplacé ni changé. Je suis juste venu travailler avec mon ordinateur portable et j'ai voulu tester l'Expert Advisor. Je n'ai qu'un seul compte et j'ai naturellement essayé de me connecter, mais le journal indique qu'il n'y a pas de connexion avec le serveur. Il s'agit peut-être d'une défaillance aléatoire, mais je n'ai rien pu faire.
Je n'ai rien déplacé ou changé. Je suis juste venu au travail avec mon ordinateur portable et j'ai voulu tester l'EA. Je n'ai qu'un seul compte et j'ai naturellement essayé de me connecter, mais le journal indique qu'il n'y a pas de connexion avec le serveur. Il s'agit peut-être d'une défaillance aléatoire, mais je n'ai rien pu faire.
Veuillez fournir une capture d'écran complète de la fenêtre du terminal, y compris toutes les zones de Market Watch, de graphique et de test.
Essayez de vous connecter au compte chez vous, d'extraire toutes les données et d'effectuer au moins un test. Déconnectez-vous ensuite de l'internet, redémarrez le terminal et réessayez.
Veuillez fournir une capture d'écran complète de la fenêtre du terminal, y compris toutes les zones de Market Watch, de graphique et de test.
Essayez de vous connecter au compte chez vous, de télécharger complètement les données et d'exécuter au moins un test. Après cela, déconnectez-vous de l'internet, redémarrez le terminal et réessayez.
Cela ne nécessite rien, car tout fonctionne comme avant. Apparemment, il s'agit d'une panne accidentelle. Auparavant, le terminal demandait une autorisation, maintenant il démarre sans autorisation. J'ai vérifié une dizaine de fois avec et sans redémarrage de l'ordinateur. Tout va bien, merci.
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
Un nouvel article Ordres, positions et transactions dans MetaTrader 5 a été publié :
La création d'un robot de trading robuste ne peut se faire sans une compréhension des mécanismes du système de trading MetaTrader 5. Le terminal client reçoit les informations sur les positions, les ordres et les transactions du serveur de trading. Pour gérer correctement ces données en utilisant le MQL5, il est nécessaire d'avoir une bonne compréhension de l'interaction entre le programme MQL5 et le terminal client.
Auteur : MetaQuotes