QUIK (версия 7.0.1.5)

Вы могли бы развернуто пояснить, при каких условиях/событиях OnTrade придет несколько раз?

На сделке, которая является сущностью торговой системы нет некоторых полей, которые есть в QUIK
В частности это UID, TRANS_ID а также набор флагов и ряд других специфичных параметров
Серверу чтобы проставить эти обновленные параметры приходится отправлять сделку несколько раз.
Иначе, отправка сделки задерживалась бы до установки всех параметров, что гораздо хуже чем получить подряд несколько обновлений.

В прежних версиях QUIK количество купленных-проданных лотов можно было брать из OnTrade(): вести подсчет trade.qty.
В данной версии это уже не будет работать так просто.
Можно, конечно, запоминать приход информации в некую базу_сделок , произвести расчеты, и по приходу следующих порций OnTrade() быстренько так глянуть в эту базу: а не было ли уже этой сделки раньше?
Пока я не вижу критериев, как удалять из этой базы сделку, так как "несколько раз" - расплывчато. Будем копить?
На таких условиях применять OnTrade() становится не очень комфортно.

Как уже было сказано и еще раз повторю, трансляция нескольких OnTrade есть, будет и от этого избавляться не планируется, по уже озвученным причинам.
Это значит что если данная реализация приводит к неудобству, предложите способ его избежать и мы зарегистрируем пожелание. Варианты типа "сделайте как было" не принимаются.
На вскидку, например можно подумать над добавлением порядкового номера обновления для каждой сущности.
1, 2, 3 и т.д. Тогда, в коде можно будет фильтровать по номеру обновления if num=1 then.

Если возражений нет, предлагаю зарегистрировать такое пожелание.

Собственно, так раньше было с OnOrder, когда он приходил по нескольку раз. В 7-й версии вместо OnOrder по нескольку раз приходят OnTrade. Причём все с абсолютно одинаковыми параметрами.
А зачем удалять? Я храню таблицы номеров пришедших заявок и сделок.
Вот действительно непонятно, зачем слать несколько одинаковых колбеков, если уже в первом приходят все параметры. Можете подробнее пояснить?

С это фичей мы уже живем дружно не первый год!   Я их обрабатываю один раз.
И чищу сразу.
Если они, коллбеки, будут как-то (например, по номерам) идентифицированы, то я готов этот вопрос не задавать.
И не спрашивать: а в чем же все-таки смысл второго и третьего отклика OnTrade()

По какому принципу чистите? После третьего колбека?
Я не чищу, потому что могут быть различные ситуации повторного прихода колбеков: переключение на другой сервер, сбой на бирже...

Лично Вам некуда спешить, а для других пользователей скорость появления сделки может быть критичной

Из кода не видно, что вы обрабатываете кобек один раз: сколько раз колбек придёт, столько раз он попадёт в таблицу trades и будет обработан функцией OnTradeDo (или orders для ордеров).

Серьезно, обновляются те поля которые пока еще не доступны в LUA

Т.е. это зависит от сервера и подобная засада может образоваться и для пользователей Quik 6-й версии?  

Вы сами ответили на свой вопрос.
Вот именно что "можно узнать" Слово "Узнать" является здесь ключевым. С точки зрения кода, оно означает прошерстить по всем записям и найти нужную из которой подхватить параметры которых на сделке нет.
Да именно так.
Потому что пользователи хотели чтобы на сделках был TRANS_ID и другие параметры

Чисто технически, да могут поменяться
Чисто практически, такая ситуация маловероятна
Да зависит от сервера. Нет на 6й версии такого поведения не будет, так как 6-я версия не поддерживает обновление таблицы сделок.

нет не будет

Для моего случая действительно проблема не одного, а нескольких повторных событий OnTrade  решилась довольно легко, путём объявления новой таблицы TradesFinished и небольшой вставки в начало обработки События OnTrade



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

OnTrade всегда приходит с заполненным полем trans_id?
Если trans_id=0 в сделке, означает ли это, что сделка была совершена вручную? Или нужно подождать второго-третьего колбека, чтобы убедиться в этом?

Раз уж разработчики сделали такой неопределённый функционал, хотелось бы, чтобы вы поделились известной для вас на текущий момент информацией, как это работает:
Какие параметры являются обновляемыми?
Сколько должно быть колбеков на одну сделку? Есть ли какое-то определённое число? Известно ли оно вам?

Ну и примерный алгоритм действий в следующей ситуации:
Задача состоит в том, чтобы при получении сделки, совершённой вручную, выполнить определённые действия. Из предыдущего комментария следует, что trans_id является обновляемым параметром, и, если там 0, то это значит, что этот параметр может быть ещё не заполнен. А может быть заполнен... В общем, надо угадать...

Насколько я понимаю, список параметров сделки является стандартным и конечным, независимо от биржи и торговой площадки.
Поэтому обозначить, какие именно параметры являются не обновляемыми для вас не составит труда.
Обновляемые параметры мы уж определим сами методом исключения.
Вы предлагаете при подаче ручного поручения пользователю забивать ещё комментарий?

Вот здесь поподробнее, пожалуйста: обновляемые параметры могут обновляться до бесконечности?

Нужно угадать как называется тот или иной биржевой параметр в вашей интерпретации?

У пользователя может быть куча других роботов, алго-приводов и пр., где параметры транзакций уже давно жёстко заданы производителем.

Отчего же? Я давно говорил и ещё раз подтверждаю:А суть такова, что проставлять нужно только те параметры, которые заведомо имеют какое-то значение. Параметры, не имеющие значений должны быть nil.
Тогда робот, получивший колбек, в котором, не проставлены интересующие его параметры, будет понимать, что нужно ждать следующего колбека.

В данной ситуации это выглядело бы так:
При получении сделки с бижи, если сервр не успел проставить номер транзакции, то он так и отправляет сделку с trans_id=nil (а не 0).
После, когда сервер будет отправлять следующий колбек, он уже проставит номер транзакции.

Но, учитывая ваш комментарий
возникает вопрос: если мы получили сделку с проставленным trans_id, можно ли рассчитывать, что он в будущем не изменится?

На сервер отправляются транзакции либо без trans_id (поданные вручную; из стакана, используя панель ввода заявок) либо с проставленным trans_id, отличным от нуля (поправьте, если ошибаюсь), поданные с помощью QLua, QPILE, API, tri-файла. Таким образом, trans_id=0 никем не зарезервирована. Следовательно, сервер, получив транзакцию без trans_id, сразу помечает её нулём, чтобы в будущем это использовать.
При отправке колбеков с сервера на терминал trans_id=0 можно использовать для обозначения, что данный параметр проставлен. Если параметр не проставлен, то он = nil.
Таким образом, получив колбек с trans_id (или любым другим параметром) = nil мы понимаем, что данный параметр не был проставлен в текущем колбеке и нужно ждать следующего колбека. Если же trans_id=0, то это будет автоматически означать, что транзакция была подана без параметра trans_id, т.е. вручную.

Я имею ввиду, что если мы получили trans_id, uid (или любой другой параметр), отличный от 0 или "", то можно ли рассчитывать, что в штатной ситуации этот параметр уже не изменится?
Это справедливо для всех параметров?

Вы что-то путаете: это вы сейчас делаете двойную работу.
Судя по сообщению #34 (вы же не опровергли его), в общем случае, сервер сначала проставляет trans_id=0, а затем проставляет правильный trans_id.

Я же предлагаю при получении транзакции от клиента сохранить эту транзакцию с trans_id, если его не было, со значением "по-умолчанию" = 0.
Далее, когда сделка приезжает на сервер, в общем случае отправлять её клиенту, раз уж транзакцию ещё не нашли, без проставленного параметра.

А когда транзакция найдётся, то проставить найденное значение параметра. И там будет либо номер транзакции либо честный ноль.

Я правильно понимаю, что весь это "сыр-бор", чтобы отправить сделку клиенту сразу по получению с биржи, не "шурша" по БД SQL в поисках недостающих параметров (в частности trans_id и uid), а эти параметры отправятся следом, когда выполнится команда SELECT?

А разве сейчас у вас 0 - не есть значение "по-умолчанию" для trans_id?
Только в текущей реализации при получении значения 0 мы не можем с уверенность сказать, действительно ли там 0 или просто сервер ещё не нашёл транзакцию.

Я предлагаю не проставлять значения, если его ещё нет. А для trans_id использовать "честный 0", чтобы отличать заявки, поданные вручную от автоматизированных.

Поясните.

Не знаю, как вы, но я борюсь за предсказуемое поведение программы: не должно быть двусмысленного толкования значений параметров.

Отсутствие значения параметра в принципе или отсутствие оного у текущего колбека? Не путайте эти два понятия.

Тогда ответьте на вопрос, который вы "не заметили":
А что сейчас происходит с trans_id, не равным 0? Почему колбеки будут сыпаться чаще?