ERR_ORDER_LOCKED 139 - что за чудовище такое?? - страница 4

 
Integer писал(а) >>

Как так может быть, если работает один советник? функции OrderSend(), OrderModify(), OrderClose() ждут завершения исполнения запроса. Ооткуда может взяться еще один запрос, если работает один советник?

,либо в связи с обработкой, которая предусмотрена условиями этого самого ордера

Например, сработал пендинг, экспирейшен или стопы этого самого ордера. Ордер приянт в обработку и заблокирован.

 

Пора, видимо, на свинобойню - совсем тупой стал. Вот ведь два предложения ответа, а до меня не доходит.

Ордер блокируется, когда сработали стопы? И это уже навсегда? Ведь это второе предложение следствие первого?

Пойду помоюсь, а потом на свинобойню.

 
stringo >>:

,либо в связи с обработкой, которая предусмотрена условиями этого самого ордера

Например, сработал пендинг, экспирейшен или стопы этого самого ордера. Ордер приянт в обработку и заблокирован.

Т.е. ордер обрабатывается неопределенно долгое время на этом ДЦ. Сработал стоп. Серверная часть это ОБРАБАТЫВАЕТ. Сутки? И дает в ответ 139. А как же проверка на наличие ордера и пр.? Что в этом неправильного и ужасного для сервера? Да нет - ничего не понимаю.

Приведите, пожалуйста, пример кода, который бы мог вызвать такую ошибку.

 

Ордер принят в обработку -> Заблокирован -> Обработан -> Разблокирован.

Имеется в виду чисто техническая блокировка для синхронизации разделения доступа.

 
stringo >>:

таки повторю вопрос

int ticket=OrderSend(Symbol(),OP_BUY,1,Ask,3,0,0);
OrderSelect(ticket,SELECT_BY_TICKET);
OrderModify(OrderTicket(),OrderOpenPrice(),Bid-100*Point,OrderTakeProfit(),0);
OrderModify(OrderTicket(),OrderOpenPrice(),OrderStopLoss(),Bid+100*Point,0);

выставляется ордер, на следующем шаге модифицируется стоплосс, на следующем меняем тейкпрофит.

может возникнуть ошибка 139?

 
Swan писал(а) >>

таки повторю вопрос

выставляется ордер, на следующем шаге модифицируется стоплосс, на следующем меняем тейкпрофит.

может возникнуть ошибка 139?

Теоретически, да. Если предыдущая операция завершилась по таймауту. То есть, ордер может быть ещё в работе на сервере, а тут уже поступает следующий приказ.

 

Так у кого проблемы? Кому код менять нужно? Советнику? Тогда как? Удалить все торговые ф-ции?)))))))

Или, может, все-таки проблема у ДЦ?

 
stringo >>:

Теоретически, да. Если предыдущая операция завершилась по таймауту. То есть, ордер может быть ещё в работе на сервере, а тут уже поступает следующий приказ.

Тогда логичный вопрос: каков (обычно) этот таймаут? В моём случае, как видим, он равен 5 минутам. Немножко дольше того что мы обычно ожидаем... :)

 
Svinozavr >>:

Так у кого проблемы? Кому код менять нужно? Советнику? Тогда как? Удалить все торговые ф-ции?)))))))

Или, может, все-таки проблема у ДЦ?

Вот у меня тоже такое подозрение. Потому как один и тот же код работает с одним и тем же брокером СЛИШКОМ по-разному на демке и в live. Если это так, можно ли изменить эксперта так чтобы этой блокировки не происходило?

 
Например, уменьшить частоту запросов
Причина обращения: