Errors, bugs, questions - page 932

 
notused:

remote agents have been dropping off regularly (a couple of times a week) for several months due to lack of space:

or

and the agent logs are either clean or:

and there's actually plenty of space:

Appears when testing something heavy (I mean, a multiview of 10 tools over a period of a year or two). It seems that at some point the agent wants to create a megafile (although there are no prints or work with files in the EA). All in all, it has become really hard to work

Counting: a year of tick history (all ticks on M1 mode) requires approximately 3Gb of disk space for temporary files (watch the folder "...\tester\Agent-0.0.0.0-xxxxx\temp", when a heavy job is running). Multiply by the number of agents. 17 Gb is already on the brink (and if you have 8 agents, you're over it).

Funny name for an Expert Advisor. ;)

PS.tester (743) gets bogged down by unnamed limits...

 

Help, please. Why does it not find the trade (error 4755)?

void OnTradeTransaction(const MqlTradeTransaction& trans,
                        const MqlTradeRequest& request,
                        const MqlTradeResult& result) {
  if ((trans.type == TRADE_TRANSACTION_DEAL_ADD) && (trans.symbol == _Symbol)) {
    if (HistoryDealSelect(trans.deal)) {
      long DealMagic;
      if (HistoryDealGetInteger(trans.deal, DEAL_MAGIC, DealMagic)) {
        //
      }
      else Print("HistoryDealGetInteger(" + (string)trans.deal + ", DEAL_MAGIC, DealMagic) = false! GetLastError() = ", GetLastError());
    }
    else Print("HistoryDealSelect(" + (string)trans.deal + ") = false! GetLastError() = ", GetLastError());
  }
}

Terminal listing:

2013.02.07 10:31:52   instant sell 0.01 EURUSD at 1.35354 (1.35354 / 1.35364 / 1.35354)
2013.02.07 10:31:52   deal #1028 sell 0.01 EURUSD at 1.35354 done (based on order #1028)
2013.02.07 10:31:52   deal performed [#1028 sell 0.01 EURUSD at 1.35354]
2013.02.07 10:31:52   order performed sell 0.01 at 1.35354 [#1028 sell 0.01 EURUSD at 1.35354]
2013.02.07 10:31:52   HistoryDealGetInteger(1028, DEAL_MAGIC, DealMagic) = false! GetLastError() = 4755
 
Ashes:

Do the math: a year of tick history (with all ticks on M1) requires about 3Gb of disk space for temporary files (watch the folder "...\tester\Agent-0.0.0.0-xxxxx\temp" when you get a heavy job). Multiply by the number of agents. 17 Gb is already on the brink (and if you have 8 agents, you're over it).

Funny name for an Expert Advisor. ;)

Thanks! Couldn't have guessed that 16GB might not be enough. Will transfer agents to another drive - 650GB will hopefully be enough.

I used to see this too - especially when my computer is busy. But lately, when computer is loaded, single test run just kills terminal (it's not because of lack of space - terminal is located where there is 650 GB of free space). But if you kill all possible processes - everything goes fine.
 
voix_kas:

Help, please. Why does it not find a trade (error 4755)?

There may be a problem with HistoryDealSelect if the code was tested in the strategy tester.

link


 
sion:

There may be a problem with HistoryDealSelect if the code was tested in the strategy tester.

ping


If I use a construction with HistorySelect(), everything works fine.

It doesn't work with OnTradeTransaction. This event probably occurs before information about the trade is placed in some database. Despite the explicit indication in the documentation:

TRADE_TRANSACTION_DEAL_ADD -adding of a trade to the history. It is performed as a result of order execution or account balance transactions.

 
voix_kas:

If I use HistorySelect(), everything works fine.

OnTradeTransaction does not work. Probably, this event occurs before information about the transaction is stored in some database. Despite the explicit indication in the documentation:

TRADE_TRANSACTION_DEAL_ADD -adding of a trade to the history. It is done as a result of execution of an order or making a transaction in the account balance.

Here we tested it worked through HistorySelect(), the same request through HistoryDealSelect already fails. On this example, the speed of placement in the database had no effect.

So in the strategy tester, do you check? On the real, most likely, will work fine.

 
sion:

Here we tested, it worked through HistorySelect(), the same request through HistoryDealSelect already fails. In this example, the speed of placement in the database had no effect.

So in the strategy tester, do you check? On the real, is likely to work fine.

I confirm, this code with castellated as HistorySelect() works fine:

void OnTradeTransaction(const MqlTradeTransaction& trans,
                        const MqlTradeRequest& request,
                        const MqlTradeResult& result) {
  if ((trans.type == TRADE_TRANSACTION_DEAL_ADD) && (trans.symbol == _Symbol)) {
    if (HistorySelect(0, TimeTradeServer())) {
      for (int i = 0; i < HistoryDealsTotal(); i++) {
        ulong Ticket = HistoryDealGetTicket(i);
        if (trans.deal == HistoryDealGetInteger(Ticket, DEAL_ORDER)) {
          Print(HistoryDealGetInteger(Ticket, DEAL_MAGIC));
          break;
        }
      }
    }
    else Log("HistorySelect(0, TimeTradeServer() = false! GetLastError() = ", GetLastError());
  }
}

It remains to wait when the developer will fix the obvious bug.

 
Yes, I check in the strategy tester. There is no problem in real time.
 
voix_kas:
Yes, I check in the strategy tester. No problem in real time.
Younz. Might come in handy, probably nothing has changed either.
 
sion:
Yountz. It may come in handy, probably nothing has changed either.

Anyway, found a workaround for my need. WithoutOnTradeTransaction.

There is an additional question concerning theHistoryDealGetTicket() function.

The documentation says that it returns the ticket number of the transaction. However the cases of error returning are not described explicitly, for example, should the returned value be checked for ">0"?

Similarly with HistoryOrderGetTicket(). However, the latter example contains the check for the positive returned value.

A search of the forum shows that people check the return value both in the case of an order and in the case of a transaction.

Most likely, such a check should be done in case, for example, of a transaction request with an order number greater than HistoryDealTotal()-1. But I was grateful to the developers for the clarity in the documentation for the MQL5 language.

Reason: