OnTradeTransaction - page 7

New comment
 
fxsaber:

Agreed. But unfortunately in MT5, unlike MT4, the trading environment may not match reality. For example, when a pending order is executed for a few milliseconds, it may not be anywhere. And even OnTradeTransaction will not help here.

Maybe, OnTrade, as I understand it is generated in the terminal itself already on the basis of transactions.

Or, do you mean that when a pending order triggers in the OnTrade handler, no new open position can be detected?

 
Aleksey Mavrin:

Maybe OnTrade, as I understand it is generated in the terminal itself based on transactions.

Or are you saying that a new open position can be undetected in the OnTrade handler when a pending order is triggered?

In any On-function. In this sense, there is a hole in MT5. It is unlikely that they will patch it.

 
fxsaber:

In any On function. In that sense, there is a hole in the MT5. It is unlikely that they will patch it.

If so, it's unfortunate. It practically loses the sense of OnTrade. We will have to check it. Ideally, OnTrade should be called approximately how many times when the order is triggered:

for stops:

- a market order is created and sent

- the pending order has been moved to the history

- the order has been executed, a deal has been recorded

- the market order has been moved to the history

- position created

for the Limit order:

- limit order activated written transaction

- pending order has been moved into the history

- position has been created

Assuming the latter, there should already be a position and not the previous ones, it is logical that there shouldn't be, eh?

I have called functions to check all trading states - trades, positions and orders - in OnTrade. So far everything seems to be working fine, but I have not had too complex trades.

 
fxsaber:

Why did I come to the forum, there are so many unresolved problems))

Thanks, I'll look into it. So far I've read the highlighted one, it's not a problem but a feature. In databases, and in general, the concept of transaction and means that ALL

necessary to perform a query and maintain the correctness of the database is done, and after the transaction can work with the database, there will be no errors.

If any action (and in order to write a row into any table it is sometimes necessary to do more than one and make sure the previous ones were done successfully)

The changes are rolled back and the transaction is rejected. Where I'm going with this, probably, you should not expect from MT the level of DBMS :)

Here all intermediate operations have to be watched and checked, again somewhere it gives more flexibility.

But everything looks nice to me - first, the server says the order is done and the terminal deletes it into the archive, then (later) the server says it opened a position and may not open due to some error, then it should be zero-zero.

I'll check it and report the results in detail.

 
Aleksey Mavrin:

But everything makes sense to me - the server first reports that the order is executed, the terminal deletes it into the archive, then (later) the server reports that it opened a position

The order is not in the history and is not among the current ones. And there is no position. I.e. there is nothing.

 
Aleksey Mavrin:

But everything makes sense to me - the server first reports that the order is executed, the terminal deletes it into the archive, then (later) the server reports that it opened a position, but it may not open due to some error, then it should be zero-zero.

I can't say on this forum or anywhere else I've read admin Renat's posts (probably Quick forum), but it seems he wrote that the only check the order goes through on the server is to provide margin requirements, then the order "flies" through the connector to the exchange, then the uncertainty of the order execution, in principle, is possible, the server does not know at what price the order is executed

 
In addition to the example given by fxsaber, in practice there is also a case where there is a ticket both among orders and among open positions. the situation also lasts for several milliseconds (not checked in the latest builds, though). the checking mechanism must be different, so be prepared in advance :)
 
Igor Zakharov:
Apart from the example given by fxsaber, in practice there is a case when there is a ticket both among orders and among open positions. this situation also lasts for several milliseconds (not checked in latest builds, though). the check mechanism should be different, so be prepared beforehand :)

This situation is handled in such a way that for MT4 EAs everything remains the same in MT5 as it is in MT4. But with phantom orders - we need to write it down.

 

On "normal" robots, the case I described, I didn't notice at all; but in one case I was asked to make a security system: the condition was that positions are always locked (either with real positions or a pending order), i.e. the number of buy lots equals the number of sell lots. This is the case that introduced me to the nuances of order/position/trade counting in a fiver.

The difference, as I explained it to myself :) is that the four, when getting an answer from the broker, first synchronizes its "tables" with open orders and history, and then informs the user about the broker's answer. The five immediately broadcasts this answer to us, and at the same time corrects its "tables" (and all mql programs read data from these "tables"). This is the moment we catch on the millisecond timer. But then, why don't we catch it in the tester?

In general, I've put up with it...

123456789
New comment
Reason: