Сергей (Все сообщения пользователя)

Добрый день. А можно уточнить, где он находится? Поиск по справке quik ничего не дал, в списке доступных параметров ТТТ тоже ничего похожего не встретилось.

Регистрируем

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

Довольно мутное свойство. Почему бы не сделать тогда флаг "находится в процессе снятия", или признак "служебного" ордера?

Видимо, я не очень доходчиво изложил свою мысль, раз до сих пор нет никакого ответа от разработчиков. Ответов в стиле "все возможно" недостаточно, нужны конкретные рекомендации, как должна быть организована выборка из таблиц квика, чтобы не было повторного чтения. Пока, из сказанного Андреем, можно сделать вывод, что таблицы заполняются терминалом не последовательно, а абы как, и порядок строк может в любой момент произвольно меняться. Если это так, то желательно иметь возможность синхронизировать чтение и обновление таблиц, либо механизмом транзакций, либо блокировками. И под словом "желательно" я подразумеваю, что необходимо зарегистрировать пожелание на доработку.

Раз уж топик про снятие заявок, внесу и свои 5 копеек. Проблем с коллбэками onTransReply не наблюдал, но зато стабильно приходят два коллбэка onOrder, причем флаг снятия ордера поднят только во втором. Получается сначала приходит коллбэк о том, что мы якобы выставили ордер (хотя он уже есть и активен), и только потом, что он снимается. Зачем такая история? Терминал 8.3.2.4, если что.

Конечно регистрировать! Это может быть весьма полезно, если был разрыв соединения, или ошибка скрипта. В таком случае коллбэк может пройти мимо, и узнать статус транзакции будет затруднительно.

Очень содержательные ответы! Почему бы просто не написать, что в нашем мире все возможно? Хочется надеяться, что более детальные комментарии службы поддержки тоже возможны, например, в каких случаях описанные проблемы могут возникнуть и как их избежать.

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

Да, тоже посмотрел, линейная. Утверждение, что  SearchItems работает быстрее, стало еще более загадочно, с чего бы?

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

Нужна какая-то особая отметка в теме, чтобы поддержка дала свои пояснения?

Как-то не совсем так. На боевом сервере (СБЕР 8.3.2.4) при начале торговой сессии каждый раз приходит 2000+ коллбэков OnFirm, файл firms.dat никак не очищается, ни скриптом, ни вручную. Значит либо терминал этот файл сам чистит (тогда в каких случаях?), либо процедура не совсем такая, как вы описали.

Немного поясню, к чему вопрос. Если SearchItems выполняется в основном контексте, то вызов с тяжелой функцией, скорее всего, заблокирует коллбэки, причем во всех скриптах. Если в контексте вызывающего потока, то одновременный вызов из main и коллбэка может привести к конфликтам.

Ну память, если не сохранять промежуточные результаты, сборщик почистит. При SearchItems тоже есть накладные расходы при вызове функции QLua из ядра Quik. Больше интересуют именно возможное блокировки данных/потоков.

Добрый день. Кто-нибудь может подсказать, есть какие-то принципиальные отличия, которые бы делали предпочтительным использование SearchItems или цикл getNumberOf/getItem для выбора значений из таблиц Quik? Одно отличие точно есть, это отсутствие трансляции ошибок при использовании SearchItems. Может еще что-то, например, блокировка таблицы, из которой идет выборка, или блокировка коллбэков?

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

[8468] {table: 00000252D3AE5D80
[8468]   sec_code="RU000A101PV6",
[8468]   awg_position_price=100.135,
[8468]   wa_position_price=100.135,
[8468]   limit_kind=1,
[8468] }
[8468] {table: 00000252D3AE7130
[8468]   sec_code="RU000A101PV6",
[8468]   awg_position_price=100.135,
[8468]   wa_position_price=100.135,
[8468]   limit_kind=2,

[8468] }
[8468] {table: 00000252D3AE7770
[8468]   sec_code="SU26209RMFS5",
[8468]   awg_position_price=1019.9716,
[8468]   wa_position_price=1019.9716,
[8468]   limit_kind=1,
[8468] }
[8468] {table: 00000252D3AE7F40
[8468]   sec_code="SU26209RMFS5",
[8468]   awg_position_price=101.99716,
[8468]   wa_position_price=101.99716,
[8468]   limit_kind=2,
[8468] }

Все оказалось еще забавнее. Если перебирать позиции по SearchItems('depo_limits'), то приходят позиции как с процентными ценами, так и в деньгах. А вот вызов getDepoEx() возвращает случайный вариант. Видимо, опять косяки с классами инструментов. Может разработчики уже как-то помогут Сберу наладить сервер? А то уже почти месяц прошел, как биржа классы меняла, а у брокера до сих пор терминал глючит!

Добрый день. Терминал Сбербанк, версия 8.3.1.38. Сегодня обнаружился очередной "прикол", по облигациям, часть позиций транслируются с балансовой ценой в рублях, часть в процентах:

[8468] {table: 00000252DD6499A0
[8468]   sec_code="RU000A1018L9",
[8468]   awg_position_price=1008.472857,
[8468]   currentbal=0,
[8468]   locked_buy_value=0,
[8468]   wa_position_price=1008.472857,
[8468]   client_code="",
[8468]   openlimit=0,
[8468]   firmid="MC0002500000",
[8468]   locked_sell_value=0,
[8468]   limit_kind=2,
[8468]   openbal=0,
[8468]   locked_buy=0,
[8468]   locked_sell=0,
[8468]   trdaccid="L01-00000F00",
[8468]   currentlimit=0,
[8468]   metatable=nil
[8468] }
[8468] {table: 00000252D3E50680
[8468]   sec_code="RU000A0JVHH1",
[8468]   awg_position_price=103.050938,
[8468]   currentbal=0,
[8468]   locked_buy_value=0,
[8468]   wa_position_price=103.050938,
[8468]   client_code="",
[8468]   openlimit=0,
[8468]   firmid="MC0002500000",
[8468]   locked_sell_value=0,
[8468]   limit_kind=2,
[8468]   openbal=0,
[8468]   locked_buy=0,
[8468]   locked_sell=0,
[8468]   trdaccid="L01-00000F00",
[8468]   currentlimit=0,
[8468]   metatable=nil
[8468] }

Причем отловить, в каких случаях какая цена придет, не получилось, все меняется случайно при каждом обращении к таблице лимитов по бумагам.

Всем доброго дня. Вопрос такой, надо ли подписываться на те параметры ТТТ, которые уже присутствуют в описании инструментов, получаемых по getItem, либо по getSecurityInfo? Или они уже заполнены корректно при получении клиентом таблицы securities?

По размышлению возник вопрос, а зачем вообще при дисконнекте закрывать потоки, созданные createdatasource()? Они автоматом разве не закроются? Что вообще произойдет с открытым потоком, если соединение разорвется, а затем восстановится?

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

Освежу темку.
1. Если фирма для брокера это группа счетов, то зачем в вызовах getDepoEx, getMoneyEx, getFuturesLimit, ... кроме номера счета указывать еще и фирму? Кажется, эта информация избыточна.
2. Практически всегда, номер счета фондового рынка МБ имеет код "L01~00000F00", получается это не счет клиента, и даже не брокера, а .... счет чего?

В эту же копилку. Выявилась еще одна проблема с таблицей "Состояние счета" в терминале от Сбера. Сегодня при подключении часть позиций в таблице оказалась с инфоклассом, вместо торгового, и отображалась какая-то дичь, вместо реального состояния счета. Разумеется, обновиться до версии 8.6 не получится, поскольку брокер ее не предоставляет.

Интересно, а подписку на получение параметров ТТТ тоже нужно делать заново при смене сессии?

Всем доброго. Еще одна проблема от Сбера. После обновления биржей классов облигаций, стал часто вылетать терминал с дампом, помогает только вход с очисткой логов. Путем проб и ошибок выяснилось, что крах наступает при обновлении таблицы "Состояние счета" (покупка/продажа облигаций, либо просто переключение фильтра по режиму торгов). Версия терминала 8.3.1.38. Может кто подскажет, как это можно быстро полечить, например, грохнуть какой-нибудь файл с кэшем инструментов?

Всем хорошего дня. Столкнулся с такой ситуацией: оповещения в скрипт о выполнении транзакции и изменении ордеров (т..е. onTransReply, onOrder) уже пришли, а стакан по getQuoteLevel2 не изменились Как с этим бороться? Ведь это проблема, "свои" заявки в стакане никак не отмечены, и определить, это "еще" объем уже выполненных ордеров, или чьи-то новые заявки, нет никакой возможности!

Спасибо

Комментарии от поддержки будут?

Вопрос был не в том, как подать, что sendTransaction, это понятно. Вопрос как посмотреть какие заявки в настоящий момент активны/исполнены, и их параметры.

Вопрос такой, каким образом можно выбрать активные алго-заявки из скрипта qlua? И как их можно снимать/модифицировать?.

Доброго дня.
Не могу понять странное значение couponvalue, возвращаемое функцией getSecurityInfo(). Например, по бумаге "SU29009RMFS6", "TQOB", значение
[23740]   couponvalue=3730, в то время, как функция getParamEx2() с параметром "CPOUPONVALUE" возвращает "37.3". Почему такая разница?