Объем импорта г/г (Imports y/y) отражает изменение объема импорта товаров и услуг в отчетном месяце по сравнению с тем же месяцем прошлого года. Показатели импорта используются для оценки внешней торговой активности Японии и спроса на импортируемые товары внутри страны. Из-за последствий "финансового кризиса" США Япония также столкнулась с...
一秒钟往往是最后一笔交易/订单的真实损失。例如,在许多漏洞中,订单进入执行阶段的TTL时间,可能是5秒。如果它在五秒钟内没有被执行,那么这个订单就是一个重定向。或者说,它被执行了,但在三秒钟内。
在这种情况下,如果从接受到执行没有任何刻度,这样的调用HistorySelect 将不会收到相关信息。
也许,TimeCurrent应该等于MathMax(LastOrder_time, MarketWatch_Time)。那么HistorySelect将是正确的。但TimeCurrent可能太贵了。
顺便说一下,这样的工作方案HistorySelect会跳过一些交易的历史。
虽然,乍一看,一切都很清楚。
在MT5中写一个便宜的DealsTotal()并不容易。这不是MT4中基本的(也是免费的)OrdersHistoryTotal()。
大声说出来的想法,没有声称自己的相关性或能力。
如果从接受到执行的过程中没有刻度,这样的对HistorySelect的调用 将不会得到相关信息。
你不会解决这个问题,服务器--终端--MQL互动的模式最初是这样设计的
我还没有达到在MT5中检查的地步,但在MT4中,我知道在有些情况下,在市场观察窗口中,我们的符号有价格变化,但可能没有刻度,或比ЕА中的刻度少。
OK,没关系,所以它的工作,你只需要选择在TS的决定,在没有从服务器的信息,从你发送的那一刻起,订单会发生什么 - 即,订单将被设置或拒绝先验,并收到答案,以确认这个初步的决定或取消 - 即,工作与未确认的信息或仍然等待从服务器的答案 - 这个报价MQ和你可能不会适合
在MT5中使用廉价的DealsTotal()并不容易。这不是MT4中基本的(也是免费的)OrdersHistoryTotal()。
不写;)
或者说,很可能你会,你将花费EA资源来维护算法,我认为你需要了解SQLite的工作原理,MQ性能测试已经说明,与大表和样本的工作正是数据库的目的--EA代码将是最小化的,所有的工作数据库将做,所有的工作归结为下订单时填充数据和服务器响应时更新(同步,当然,当你运行EA时,数据库在内存中。)
但你不会的;)
或者说,很可能你会写,并将花费EA资源来维护算法,我认为你需要了解SQLite的工作原理,MQ性能测试表示,与大表和样本的工作正是数据库的目的 - EA代码将是最小化的,所有的工作数据库将为你做,所有的工作将归结为下订单时填充数据和从服务器响应时更新(同步,当然在运行EA时,数据库在内存中)。
这是最初写的,也是贴的。它不太可能变得更快。
这是最初写的,也是贴的。它不太可能变得更快。
我一定是看错了这个任务。
我认为我需要从OnTradeTransaction() 和OnTick()两个点来更新订单列表,因此我建议在数据库中这样做。
以下是我的代码。在初始化过程中,它在表中创建了一条记录。在OnTick主体中,它应该立即返回一个错误,因为我试图添加一个具有相同PRIMARY KEY的记录,之后基地立即关闭。但与此同时,当我打开它时,我至少应该看到第一条记录,但当我在测试器中运行它时,它却不在那里。甚至连表也没有创建。如果我只是在终端打开它,一切都很正常。第一个记录在那里。
与数据库的位置,你不乱了希望吗?
你不会对基地的位置感到困惑吧?
不,我没有。一切都在文件中。我认为在测试者模式下,数据库是在内存中创建的,并在测试后销毁。
大声说出来的想法,没有声称自己的相关性或能力。
...
或者说,很可能你会写,并将花费EA资源来维护算法,我想你需要找出SQLite的工作原理,MQ性能测试表示,与大表和样本的工作正是数据库的目的 -EA代码将是最小化的,所有的工作数据库将做你, 所有的工作被减少到填充数据时下订单和更新时从服务器响应(同步,当然,当运行EA,数据库在内存)。
那么什么数据库会完成你所有的工作呢?你能告诉我吗?
通信是通过数据库或通过PUB/SUB ZMQ。当然数据库不是SQLite。 最适合这些目的的是Redis,当然是我的个人意见。
祝好运