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

Выбрать дату в календареВыбрать дату в календаре

Страницы: 1 2 След.
Возможно ли в OnTransReply получение номера снимаемой/передвигаемой заявки?, при использовании Move/Kill order
 
Цитата
Roman Azarov написал:
Юрий Балашов, добрый день!

В ответе на транзакцию снятия заявки (KILL_ORDER) номер снимаемой заявки  не  приходит.
В ответе на транзакцию передвижения заявки (MOVE_ORDERS) приходит только номер  новой  заявки.

Также, заметим, что данный ответ идет от Торговой Системы, а не от терминала.
Спасибо.
Возможно ли в OnTransReply получение номера снимаемой/передвигаемой заявки?, при использовании Move/Kill order
 
Цитата
Nikolay написал:
Ели транзакция прошла успешно, то номер снимаемого ордера заполнен в ответе транзакции.
Если возникла ошибка то он не заполнен. Но у Вас есть структура, где по номеру транзакции есть номер ордера по которому возникла ошибка.
Ели транзакция прошла успешно, то номер снимаемого ордера мне не нужен.
Ели транзакция не прошла, то безусловно, я могу восстановить номер снимаемого ордера, но только в том случае, если я его сохранил. Т.е. я должен вначале сохранить параметры этой заявки, потом, если снятие этого ордера не произошло, по ID провести поиск этого номера и только затем повторить снятие этого ордера или убедиться, что он исполнен. Зачем эти "танцы с бубном"?  Насколько проще бы было если можно вытащить номер СНИМАЕМОЙ заявки из колбэка и прямо по нему произвести необходимые действия.
Поэтому и был вопрос - возможно ли это?
Ответ хотелось бы получить в форме:
Нет, не возможно или Да, возможно, вот таким образом.
Странно, почему молчит техподдержка?
Возможно ли в OnTransReply получение номера снимаемой/передвигаемой заявки?, при использовании Move/Kill order
 
Цитата
s_mike@rambler.ru написал:
Николай вам ответил правильно.

при подаче транзакции на снятие запоминайте ее trans_id (не номер заявки), и в колбеке ждите этот trans_id
Николай мне ответил неправильно:(.
Внимательно прочтите пой предыдущий пост.
Еще раз повторю - мне не нужен ID отправляемой заявки, как вы правильно отметили, я его знаю и в колбэке он естественно приходит. Мне нужен номер заявки или ID той транзакции которую он должен снять. Этот номер заявки (которую необходимо снять) я отправляю в Килл ордере, но вот в колбэке, если снятие заявки по какой-то причине не произошло, я его выловить не могу.
Ребята, без обид, кто не очень въехал о чем речь, не надо отвечать.
По прежнему жду ответа от ТЕХПОДДЕРЖКИ возможно ли это в принципе или нет?
Возможно ли в OnTransReply получение номера снимаемой/передвигаемой заявки?, при использовании Move/Kill order
 
Цитата
Nikolay написал:
Если задача перехватить ответ для отправленной транзакции, то это лучше делать по номеру транзакции, который был передан. Номер транзакции тоже известен при ее подаче, а ответ этот номер содержит.
Николай, Вы немного не понимаете о чем идет речь, по-видимому Вы никогда не сталкивались с подобной ситуацией. Нет задачи перехватить ответ для ОТПРАВЛЕННОЙ Килл/Мув транзакции, ее ID и так известен, задача в том, чтобы узнать номер транзакции (или ID) того ордера который она снимает/передвигает, если вдруг заявка Килл/Мув неудачна, что бывает достаточно часто, особенно последнее время.

Прошу ТЕХПОДДЕРЖКУ ответить на поставленный вопрос.
Возможно ли в OnTransReply получение номера снимаемой/передвигаемой заявки?, при использовании Move/Kill order
 
Цитата
Nikolay написал:
Чтобы снять ордер надо знать его номер, а если он известен, то зачем его получать в колбеке?
Затем, что заявок на снятие и передвижение может быть несколько и если одна из них прошла с ошибкой, надо знать какая, чтобы скорректировать поведение робота. ID заявки на снятие/передвижение есть, а вот номер ордера СНИМАЕМОЙ заявки я получить не могу.Если это теоретически возможно, то я не понимаю как? Хотя действительно номер снимаемой заявки передавался в Килл/Мув ордере.  
Возможно ли в OnTransReply получение номера снимаемой/передвигаемой заявки?, при использовании Move/Kill order
 
Собственно весь вопрос в заголовке: возможно ли в OnTransReply получение номера снимаемой/передвигаемой заявки при использовании Kill/Move order по ID этого ордера?
Неправильная работа TRANS2QUIK.DLL после перехода на 19-значные номера заявок и сделок, тип данных double не может вместить 19 знаков корректно
 
Цитата
Ivan Smirnov написал:
Спасибо, на новой версии все вроде заработало.
Иван, как Вы состыковали свою программу с Trans2QuikAPI_1.3_x64 ?
Вам удалось написать Quik.pas или Вы используете не Delphi?
Сбой передачи данных по ODBC при переходе на 19-тизначный номер заявки, Сбой передачи данных по ODBC при переходе на 19-тизначный номер заявки
 
Цитата
Sergey Gorokhov написал:
К сожалению произошла ошибка, через терминал QUIK при экспорте по ODBC передать параметр номера заявки в виде числа нельзя.
Альтернативный вариант в виде использования QPILE таблиц, где указать строковое значение в виде номера заявки, далее эту таблицу сохранять по ODBC.
Вы наверное описались, когда пишите, что "передать параметр номера заявки в виде ЧИСЛА нельзя" и имели ввиду что в виде СТРОКИ нельзя?
Не могли бы Вы дать ссылку как создать таблицу при помощи QPILE.
Цитата
Sergey Gorokhov написал:

Цитата
Юрий Балашов написал:
Вы можете сказать, на каких КОНКРЕТНО базах данных, желательно с версией базы, такая передача данных проверялась.
нет не можем.
на MSSQL совершенно точно проблем не обнаружено, можете использовать ее.
Это секретные данные???
MSSQL слишком специфичная база, не могли бы Вы сказать будет ли работать на базе Oracle 8?
Сбой передачи данных по ODBC при переходе на 19-тизначный номер заявки, Сбой передачи данных по ODBC при переходе на 19-тизначный номер заявки
 
Цитата
Sergey Gorokhov написал:
на разных базах, но FB точно не проверялся.
Вы можете сказать, на каких КОНКРЕТНО базах данных, желательно с версией базы, такая передача данных проверялась.
Сбой передачи данных по ODBC при переходе на 19-тизначный номер заявки, Сбой передачи данных по ODBC при переходе на 19-тизначный номер заявки
 
В соседнем обсуждении Вы пишите, что номер заявки передается как строковый, я попробовал, но Квик (версия 8.5) не дает возможности передать в базу данных строку "Номер" заявки как строковую переменную, только как числовую.
Неправильная работа TRANS2QUIK.DLL после перехода на 19-значные номера заявок и сделок, тип данных double не может вместить 19 знаков корректно
 
Цитата
Sergey Gorokhov написал:
Здравствуйте,
Используйте версию 1.3, которая вышла уже очень много лет назад.
Скачать можно на нашем сайте  https://arqatech.com/upload/iblock/80a/Trans2QuikAPI_1.3_x64.zip
Версия конечно существует, но к ней нет образца Quik.pas на Delphi, который был у версии 1.2, а так как они принципиально отличаются мне, например, не удается его написать.
Кстати просьба ко всем форумчанам, если кому-то удалось это сделать, не могли бы Вы поделиться, я был бы очень признателен.
Сбой передачи данных по ODBC при переходе на 19-тизначный номер заявки, Сбой передачи данных по ODBC при переходе на 19-тизначный номер заявки
 
Вдогонку, можно ли передать номер заявки как строковый?
Сбой передачи данных по ODBC при переходе на 19-тизначный номер заявки, Сбой передачи данных по ODBC при переходе на 19-тизначный номер заявки
 
Цитата
Sergey Gorokhov написал:

Дополним,
Если проблема действительно в FB то обновление терминала никак не поможет.
ответ следует искать на форумах где обсуждается FB.
Еще можно попробовать изменить тип данных в самой базе.
Да, проблема действительно в FB, Квик передает данные, но усеченные, не все 19 цифр. Поэтому и был вопрос, на какой базе данных тестировали передачу данных по ODBC?
На какой тип данных изменить, в самой базе у меня стоит DOUBLE PRECISION?
Сбой передачи данных по ODBC при переходе на 19-тизначный номер заявки, Сбой передачи данных по ODBC при переходе на 19-тизначный номер заявки
 
Сегодня, при переходе на 19-тизначный номер заявки произошел сбой передачи данных по ODBC и соответственно робот встал :(. База на FB сервере, система Win7, Квик 8.5.2.11, Брокер - Кит_Финанс. Насколько я понимаю причина в том, что FB не поддерживает 19 знаков. На какую базу можно перейти? Надеюсь разработчики не отказались полностью от передачи данных по ODBC и тестировали ее хоть на какой-то базе?

Кстати, теперь номер заявки идет не по порядку выставления заявки, а по какому-то другому принципу. Например заявки по SiU0 имеет меньший номер чем GDU0, даже если она была выставлена намного позже. Так и было задумано или это какой-то сбой? И как теперь упорядочить таблицу заявок?
Сбой передачи данных по ODBC из таблицы заявок, Сбой передачи данных по ODBC из таблицы заявок после изменений на бирже от 13.12.2019
 
Цитата
Юрий Балашов написал:
1. В базу данных не передается ID_транзакции (причем сбой весьма странный, как правило передается значение "null" и лишь иногда передается правильное значение).
2. Параметр "Состояние" передается правильно только в первый раз, а именно состояние "Активна", при снятии заявки или ее исполнении, в базу данных по прежнему передается состояние "Активна".
В версии Квик 8.3 эти ошибки исчезли.
Выходит я был прав, 8.2 была не полностью рабочей и на тот момент полностью рабочих версий не было :(((.
Сбой передачи данных по ODBC из таблицы заявок, Сбой передачи данных по ODBC из таблицы заявок после изменений на бирже от 13.12.2019
 
Добрый день.
По Вашему требованию я перешел на Windows7(х64) и Квик 8.2.1.13. Однако в этой связке также ошибки на позволяющие работать. При передаче данных по ODBC из "Таблицы заявок":
1. В базу данных не передается ID_транзакции (причем сбой весьма странный, как правило передается значение "null" и лишь иногда передается правильное значение).
2. Параметр "Состояние" передается правильно только в первый раз, а именно состояние "Активна", при снятии заявки или ее исполнении, в базу данных по прежнему передается состояние "Активна". Если же прекратить передачу данных и снова возобновить ее при активном пункте "Чистить таблицу перед выводом" изменившиеся ранее данные передаются правильно, но во вновь выставленных заявках состояние по прежнему всегда  "Активна" вне зависимости от произошедших изменений. Такое ощущение, что передается только первое поступившее значение, дальнейшие изменения уже не передаются.
Остальные, используемые мной параметры передаются правильно.
Файл  quik_odbc.log в этом случае заполняется, причем чрезвычайно быстро (за несколько дней до 11Гбт).
По-видимому Вам требуется архив рабочего места QUIK и quik_odbc.log? Скажите, как их передать?  
Сбой передачи данных по ODBC из таблицы заявок, Сбой передачи данных по ODBC из таблицы заявок после изменений на бирже от 13.12.2019
 
Цитата
Для устаревшей версии терминала QUIK x86 подобных доработок не предусмотрено.
Т.е. как? Получается, что на данный момент не существует полноценно работающей версии Квик? Версия 7 не передает данные по ODBC и Вы не собираетесь ничего исправлять, а версия 8.2, как сказал мне брокер, не является рабочей и распространяется только в тестовом режиме.
И какие доработки? Просто укажите тип данных для поля "Номер" из "Таблицы заявок", ведь Win32 позволяет передать 15-ти значное целое число, в чем проблема?
Сбой передачи данных по ODBC из таблицы заявок, Сбой передачи данных по ODBC из таблицы заявок после изменений на бирже от 13.12.2019
 
Цитата
Вы пробовали именно на x64 Windows совместно с QUIK 8.2.1? В этой связке работать должно. Если не работает - присылайте ранее запрошенные подробности, будем разбираться.
Нет, я пробовал с Квиком версии 7.25.1.3.
А что относительно существующей проблемы на Win32? Есть какие-либо сдвиги в ее решении?
Сбой передачи данных по ODBC из таблицы заявок, Сбой передачи данных по ODBC из таблицы заявок после изменений на бирже от 13.12.2019
 
Уважаемые разработчики!
Пугает отсутствие реакции на мои последние сообщения. Ответьте хотя бы, что Вы их видели, занимаетесь ли вопросом и когда приблизительно можно ожидать разрешение проблемы?
Поймите меня правильно, у меня работа ПОЛНОСТЬЮ стала!
Может быть нужна какая-либо помощь с моей стороны?
Сбой передачи данных по ODBC из таблицы заявок, Сбой передачи данных по ODBC из таблицы заявок после изменений на бирже от 13.12.2019
 
При попытке логирования, создании файла quik_odbc.log и последующем воспроизведении проблемы он также, как и на WIN32 остается пустым.
Сбой передачи данных по ODBC из таблицы заявок, Сбой передачи данных по ODBC из таблицы заявок после изменений на бирже от 13.12.2019
 
Несмотря на отсутствие возможности мне удалось проверить на 64 разрядном Windows.
Ситуация с передачей данных по ODBC усугубилась: не только не передаются данные из таблицы заявок (напомню в базе все поля передающиеся из этой таблицы равны null), но и перестала передаваться часть данных из "Текущей таблицы параметров", а именно, поля соответствующие параметрам "Спрос", "Предл.", "Цена послед." также стали равны null.
Сбой передачи данных по ODBC из таблицы заявок, Сбой передачи данных по ODBC из таблицы заявок после изменений на бирже от 13.12.2019
 
Какая версия не будет работать в Win32 моя 7.25.1 или 8.2.1?
Если Вы говорите, что в версии 8.2.1 была исправлена похожая проблема, то почему бы ее не исправить в версии которая всеми используется сейчас - 7.25? Т.е. проблема все-таки есть и не думаю, что я один использую протоколы ODBC и DDE. К тому же я не очень понимаю в чем принципиальная сложность, ведь в Win32 при типе данных DOUBLE PRECISION спокойно передается 15 цифр?
В будущем я планировал постепенно переходить на 64 разрядную систему, но в данный момент это практически невозможно. К тому же я вовсе не уверен, что без частично переделки программы она будет работать на Win64, а это время, и немалое, а работать мне надо СЕЙЧАС! И согласитесь, не очень прилично, без предварительного предупреждения, менять что-то, что приведет к остановке работы Ваших клиентов?
С моей стороны, я готов на любую помощь в устранении этой ошибки, при необходимости могу прислать архив программы или саму базу, провести любое логирование.
Сбой передачи данных по ODBC из таблицы заявок, Сбой передачи данных по ODBC из таблицы заявок после изменений на бирже от 13.12.2019
 
Добрый день!
Не все моменты Вашего ответа понятны:
1. Что значит архив пустой? Все таблицы пустые? Такое вообще возможно? Или он не полностью прошел? По совету брокера я перед архивацией архива удалил папки archive, backup, Doc, м.б. дело в этом? Давайте я снова перешлю Вам архив, только укажите почту куда отправлять.
2. Не понятен смысл фразы "Сообщите какой именно номер экспортируется (посмотрите в QUIK)", что имеется ввиду, где в Квике смотреть и какой номер (брокер в этом вопросе тоже помочь не смог)??? Если имеется ввиду столбец "Номер" из таблицы заявок, то структуру базы привожу ниже.
3. Структура базы данных для таблицы заявок:
Столбец таблицы Квик (Список параметров)                                             Поле, соответствующее параметру
1. Номер *                                                                                                ORDERKEY (DOUBLE PRECISION)
2. Операция                                                                                             OPER (VARCHAR(10))
3. Цена                                                                                                    P (DOUBLE PRECISION)
4. Количество                                                                                           V (INTEGER)
5. Остаток                                                                                                OST (INTEGER)
6. Состояние                                                                                            SOSTO (VARCHAR(15))
7. Код инструмента                                                                                  KB (VARCHAR(12))
8. ID транзакции                                                                                       TRANS_ID (INTEGER)
9. Код класса *                                                                                        KODK (VARCHAR(10))


Кроме того если в базу данных в поле соответствующее полю "Номер" из "Таблицы заявок" вручную ввести 14 цифр, то они прекрасно сохраняются там, однако Квик их по каким-то причинам передать не может.
Сбой передачи данных по ODBC из таблицы заявок, Сбой передачи данных по ODBC из таблицы заявок после изменений на бирже от 13.12.2019
 
Архив отправил.
Добавлю, что удалось выяснить мне:
1. Сбой идет при передаче данных по ODBC из "Таблицы заявок" (ошибка в Квике появляется при запуске вывода из этой таблицы)
2. Сбой связан со столбцами либо "Номер", либо "Код класса" (оба параметра обязательны), т.к. я в базе пробовал убирать остальные параметры, но ошибка не исчезает.
3. Наиболее вероятно, что ошибка связана со столбцом "Номер", т.к. его длина поменялась 13.12.2019, а "Код класса" не менялся.
4. По документации параметр "Номер" д.б. "DOUBLE PRECISION" (как стоит у меня), в порядке эксперимента я пробовал менять его на  NUMERIC, Size 15, Scale 1, и DECIMAL 15, 1 - не помогает.
Все вышесказанное только мое мнение и написано только для дополнения информации. Ошибка м.б. в чем-то совершенно другом.
Еще раз напомню База на FB сервере, система WinXP32.
Сбой передачи данных по ODBC из таблицы заявок, Сбой передачи данных по ODBC из таблицы заявок после изменений на бирже от 13.12.2019
 
Перепроверил, файл называется quik_odbc.log
Сбой передачи данных по ODBC из таблицы заявок, Сбой передачи данных по ODBC из таблицы заявок после изменений на бирже от 13.12.2019
 
Да, забыл уточнить, заявок по режиму GCTR нет.
Сбой передачи данных по ODBC из таблицы заявок, Сбой передачи данных по ODBC из таблицы заявок после изменений на бирже от 13.12.2019
 
Спасибо за быстрый ответ.
Логирование провел.
Однако, после запуска Квика и воспроизведения проблемы файл quik_odbc.log остается пустым, хотя во время работы Квика он недоступен. Чтобы устранить возможные ошибки с моей стороны опишу как проводил логирование: выключил Квик, в папке где расположен файл info.exe создал текстовый документ, который переименовал в quik_odbc.log, запустил Квик, при его  запуске автоматически запустилась передача данных по ODBC, в Квике по прежнему выскочила ошибка (Dynamic SQL Error SQL error code =-104 Token unknown - line1 column 862) в количестве, равном количеству строк в "Таблице заявок". Выставил заявки, в Квике появились еще строки с указанной ошибкой. Остановил Квик. Пустой лог-файл выслал через брокера (т.к. пустой лог-файл не отправлялся пришлось его заархивировать).
Сбой передачи данных по ODBC из таблицы заявок, Сбой передачи данных по ODBC из таблицы заявок после изменений на бирже от 13.12.2019
 
После изменений на бирже от 13.12.2019 данные из "Талицы Заявок", не передаются по ODBC, по-видимому изменился тип данных одного из столбцов. Если это так, прошу уточнить какого (или каких)?  Если причина другая, поясните, что надо исправить? База на FB сервере, система WinXP32, Квик 7.25.1.3, Брокер - Кит_Финанс.
Не выставилась заявка при синхронной отправки транзакции
 
Возвращаясь к проблеме ORDERKEY (ordernum) равен 0. Кто-нибудь сможет объяснить ответ на транзакцию, который прислала биржа:
"ORDERKEY = 0; Message = (210) Снято заявок: 1. Снято количество: 40. Нельзя снимать: 0."
С одной стороны пишет, что заявка снята и снято все количество, а с другой стороны - "Нельзя снимать: 0" - как это понимать?
Не выставилась заявка при синхронной отправки транзакции
 
Спасибо!
1. Как проверить причину по которой биржа сняла заявку?
2. Всегда ли когда ORDERKEY (ordernum) оказался равен 0 заявка не выставляется (или соответственно не передвигается, не убивается - в зависимости от вида заявки move, kill )? Или возможны варианты, что она все-таки выставилась, передвинулась, убилась?
Не выставилась заявка при синхронной отправки транзакции
 
Это единичный сбой, до этого подобных ошибок не было, но тем не менее, раз случилось, то может повториться:
При синхронной отправке транзакции на продажу акций пришло сообщение об успешном ее исполнении, а также ее TRANS_ID, но ORDERKEY (ordernum) оказался равен 0. Количество акций необходимых для продажи присутствует.
Вопросы:
1. Как такое возможно?
2. Что делать, чтобы такое не повторялось?
3. Как контролировать такую ошибку?
MOVE_ORDERS на ММВБ, Планируется ли введение MOVE_ORDERS на рынке акции ММВБ?
 
Сейчас ACTION = MOVE_ORDERS на рынке акции ММВБ не работает.
1. Существует ли веская причина этого?
2. Планируется ли ввести передвижение заявок для акций, с целью снижения нагрузки на сервера биржи?
3. Если этот вопрос не поднимался, прошу зарегистрировать его как пожелание.
Неправильный ответ при запросе "Код класса", Неправильный ответ для акций при запросе "Код класса" из таблицы текущих параметров
 
Sergey Gorokhov,
Мне казалось, что код TQBR правильный, а EQRP_INFO это что-то не то, просто потому, что так написано в таблице и на сайте биржи.
Но, допустим EQRP_INFO тоже правильный код, тогда почему при следующем запросе:
Код
function OnParam(class, sec)
      if (class ==class1 and  sec == instr1) then
      Spros = tonumber(getParamEx(class, sec, "bid").param_value)
      SprosV = tonumber(getParamEx(class, sec, "BIDDEPTH").param_value)
      end
end 
для фьючерса значение спроса и его объема выдаются, а для акций нет?
Неправильный ответ при запросе "Код класса", Неправильный ответ для акций при запросе "Код класса" из таблицы текущих параметров
 
Что, никто не может ответить???
Звонил брокеру - сказали вопросы к разработчикам.
Мне самому кажется подобная ситуация невероятной, ведь в таблице class_code отражается верно. Но ведь против фактов не попрешь, или у Вас не воспроизводится данный результат?
Неправильный ответ при запросе "Код класса", Неправильный ответ для акций при запросе "Код класса" из таблицы текущих параметров
 
При запросе из скрипта QLua "Код класса" из "Текущей таблицы параметров" для фьючерсов код выдается правильный - "SPBFUT", а для акций - нет: вместо TQBR выдается код EQRP_INFO. Хотя в самой таблице он отображается правильно. Естественно, что при попытке использовать полученный class_code в функции OnParam(classs,sec) нужные данные не получаются. Что нужно сделать для исправления?
Код запроса:
Код
if sec[i] ~= nil then
class[i] = getSecurityInfo("",(sec[i])).class_code
message(sec[i].."/"..class[i]) 
end

Квик - 7.7.0.89, Брокер - КитФинанс, Винда - ХР.
Потеря 16 млсек., При обращении к Квику происходит потеря 16 млсек.
 
Спасибо!
Потеря 16 млсек., При обращении к Квику происходит потеря 16 млсек.
 
При обращении к Квику, даже если в этот момент Квик не обновляет данные и не производит никаких вычислений, происходит потеря 16 млсек. Поясню на примере. Если выполнить следующий простенький скрипт, написанный на Lua:

IsRun = true
    local time = os.clock()
    for i = 0, 20 do
       message(string.format('Цикл № %0.0f ,Время %0.3f сек',i, os.clock()-time), 1)
    end
function main()
   while IsRun do
   sleep(1000)
   end
end
function OnStop()
  IsRun = false
end

то увидим следующий результат:
Дата    Время    Сообщение
15.02.2017    13:24:11    Цикл № 0 ,Время 0.000 сек
15.02.2017    13:24:11    Цикл № 1 ,Время 0.016 сек
15.02.2017    13:24:11    Цикл № 2 ,Время 0.016 сек
15.02.2017    13:24:11    Цикл № 3 ,Время 0.032 сек
15.02.2017    13:24:11    Цикл № 4 ,Время 0.032 сек
15.02.2017    13:24:11    Цикл № 5 ,Время 0.032 сек
15.02.2017    13:24:11    Цикл № 6 ,Время 0.032 сек
15.02.2017    13:24:11    Цикл № 7 ,Время 0.047 сек
15.02.2017    13:24:11    Цикл № 8 ,Время 0.047 сек
15.02.2017    13:24:11    Цикл № 9 ,Время 0.063 сек
15.02.2017    13:24:11    Цикл № 10 ,Время 0.063 сек
15.02.2017    13:24:11    Цикл № 11 ,Время 0.079 сек
15.02.2017    13:24:11    Цикл № 12 ,Время 0.079 сек
15.02.2017    13:24:11    Цикл № 13 ,Время 0.079 сек
15.02.2017    13:24:11    Цикл № 14 ,Время 0.079 сек
15.02.2017    13:24:11    Цикл № 15 ,Время 0.094 сек
15.02.2017    13:24:11    Цикл № 16 ,Время 0.094 сек
15.02.2017    13:24:11    Цикл № 17 ,Время 0.094 сек
15.02.2017    13:24:11    Цикл № 18 ,Время 0.110 сек
15.02.2017    13:24:11    Цикл № 19 ,Время 0.110 сек
15.02.2017    13:24:11    Цикл № 20 ,Время 0.110 сек
Из которого видно, что в среднем, за каждые 3-3.5 обработки в Lua теряются 16 млсек (иногда 15 млсек). При этом никаких вычислений у нас не происходит и Квик может даже не получать никаких данных (я проверял и в выходные - результат тот же). Аналогичное время теряется и при выводе через ODBC, думаю, что при выводе данных через DDE будет то же самое ( не проверял). Отсюда логично сделать вывод о том, что это какие-то потери Квика.
При исполнении данного примера, но, если вывод происходит внутри function main(), потери 16 млсек тоже наблюдаются, но существенно реже.
Хотелось бы понять из-за чего это происходит? Можно ли каким-то образом уменьшить это время потерь или хотя бы частоту их появления?
Допускаю, что что-то можно изменить в настройках Квика или его загрузке, тогда подскажите что? "Вывод по ODBC", "Экспорт в системы тех.анализа" и "Внешние транзакции" никак не влияют.
Возможно, что потеря именно данного времени (16 млсек) может быть как-то связана с характеристиками машины и операционной системы ( у меня Win XP, Квик 7.7.0.89), поэтому, кто сможет, проверьте на своих машинах и выложите сюда результат, было бы интересно сравнить.
Очередность поступления данных в таблицы Квика, В какой очередности данные поступают в различные таблицы Квика?
 
Все проще, я могу брать одни и те же данные из разных таблиц. Хотелось бы знать из каких предпочтительнее., т.е. никакого желания схалтурить нет:). А на счет "все приезжает в случайном порядке" Вы не правы, я сам, правда давно, больше 3 лет назад, наблюдал, как в некоторые таблицы информация приходила с запазданием. Вот и хотелось услышать от создателей, что к чему, т.к. брокер полностью прояснить данный вопрос не смог.
Очередность поступления данных в таблицы Квика, В какой очередности данные поступают в различные таблицы Квика?
 
Для оптимизации работы робота хотелось бы узнать в какой очередности данные поступают в различные таблицы Квика и насколько (в % или млсек) отличается скорость постановки этих данных?
Интересуют следующие таблицы:
"стакан"
Таблица заявок
Текущая таблица параметров
Позиции по клиентским счетам
Таблица лимитов по бумагам
Таблица транзакций
Таблица лимитов по денежным средствам
Ограничения по клиентским счетам

В свободном доступе я этой информации не нашел.
С уважением
Требования к роботу, Какова скорость и надежность работы робота написанного на Lua?
 
Да, похоже Вы правы, поэтому прихожу к заключению,что придется писать скрипт на Lua по передачи данных через DLL в Delphi.
Если кто-нибудь знает, подскажите примеры таких DLL, никогда не поверю, что их никто не писал.
Требования к роботу, Какова скорость и надежность работы робота написанного на Lua?
 
Хочу написать робота-арбитражера для парного трейдинга с акциями и фьючерсами, главные требования:
1. Скорость работы – максимально быстрая скорость постановки, снятия и перестановки заявки при изменении цены в стакане – желательно не более 0.1сек.
2. Отсутствие торможения – отсутствие замедления и сбоев в работе при выставлении заявок по 15-20 парам инструментов, при отслеживании до 40-60 пар (отслеживание возможно не в режиме реального времени, а периодически – 1раз в 1-5 минут).
Не нужно: никаких графиков, индикаторов, проверки на истории, возможностей постановки заявок вручную.
Собственно такой робот у меня есть (написан мной на Delphi), но он работает через передачу по ODBC в базу данных и затем чтения из нее, что замедляет постановку заявки более чем на 1.5 секи и при работе более чем с 8-10 парами начинаются сбои в постановке/снятии заявок.
Вопрос: возможно ли написание подобного робота, отвечающего указанным выше требованиям на, Lua или Lua + внешняя программа (С#, Delphi)?
Поскольку Lua не знаю совершенно, не хотелось бы оказаться в положении человека изучившего Lua, написавшего на нем робота и вдруг выяснившего, что скорость постановки заявки будет медленная и работать можно будет только с 2-3 парами инструментов :).
Ошибка при выводе волатильности в МетаСток, Данные в Метесток выводятся некорректно
 
Все запрошенные файлы отправил
Ошибка при выводе волатильности в МетаСток, Данные в Метесток выводятся некорректно
 
Уважаемый Stanislav!
Спасибо, что откликнулись, т.к. Ваш коллега из техподдержки, который отвечал мне на почту, просто вежливо "послал" меня, не пожелав даже вникнуть в суть вопроса. Хотелось бы, что бы в дальнейшем рассмотрением проблемы занимался не он.
Отправил на саппорт оба запрашиваемых Вами файла, созданных таким образом, чтобы можно было проще разобраться в теме: в МетаСток передаются только 2 инструмента VolSi - волатильность опциона на фьючерс доллара SiZ5, который передается с ошибкой и VolBr - волатильность опциона на фьючерс нефти BRZ5, который передается без ошибки.
В строчках файла quik_metastock.log я различий не нашел, но я и не специалист в этой области. Однако в файле __iwr.log четко видны различия, так  VolBr передается со знаками после запятой, а VolSi  без знаков после запятой, т.е. с ошибкой:
[2015-11-20 10:02:34.218] EXE: Sending quote to client: (2015-11-20 10:00:00 1 VOLSI 19
[2015-11-20 10:02:34.218] EXE: Sending quote to client: (2015-11-20 10:00:00 1 VOLBR 43.08

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

"Позволим себе усомниться в Ваших выводах, т.к. в quik_metastock.log данные пишутся уже на выходе из QUIK, и в дальнейшем никак нашим софтом не трансформируются. То есть в данном файле данные находятся уже в том виде, в котором их будет принимать Метасток. По какой причине он округляет эти данные - для нас непонятно. Мы рекомендуем Вам обратиться в поддержку Метасток и после обнаружения причины проблемы, если Вам не сложно, сообщить её решение нам."

Вы зря сомневаетесь в моих выводах, поскольку  МетаСток ничего не знает из какого источника мы присылаем ему данные, файл в который мы отправляем эти данные мы специально не меняем, меняя только источник данных в Квике. Значит данные передаваемые правильно и передаваемые неправильно чем-то отличаются (не смотря на то, что в quik_metastock.log конкретные цифры волатильности отражаются со знаками после запятой), иначе МетаСток их просто не смог бы отличить.
Очень прошу Вас воспроизвести описанную ранее процедуру вывода данных в МетаСток на своих компьютерах и, если Вас не затруднит, сообщить мне результат.
Обратиться в поддержку МетаСтока я к сожалению не могу, т.к. последняя известная мне служба поддержки перестала работать. Если у Вас есть такая возможность, я был бы Вам очень признателен, если бы Вы обратились к ним, думаю Вам это намного проще, чем мне. Хотя я по прежнему уверен: проблема в том, что в МетаСток из Квика передаются несколько разные данные (возможно по формату, возможно по каким либо другим параметрам).
Ошибка при выводе волатильности в МетаСток, Данные в Метесток выводятся некорректно
 
Ошибка при выводе волатильности возникает не для всех опционов, например для BR, ED ее нет, а для Si, RI, LK, GZ она наблюдается и связана она абсолютно точно с Квиком. Это очевидно если провести следующие действия:
1. Создать в DownLoader МетаСтока новое Security с любым Именем.
2. В Экспорте Данных Квика добавить новую Бумагу - например Опционы FORTS - BRZ5 - выбрать любой опцион - В "Обозначение в системе ТА" ввести выбранное Имя из созданного Секьюрити Метастока -  выбрать "Таблица истории значений параметров" - Волатильность опциона.
3. Начать вывод по бумаге.
4. Подождать несколько минут, убедившись, что волатильность в МетаСток выводится без ошибки (т.е. без округления)
5. Затем в  Квике "Прекратить вывод по бумаге" - нажать кнопку "Изменить"
6. Заменить опцион BRZ5 на опцион SiZ5 не меняя "Обозначение в системе ТА" - т.е. выводить данные в тоже самое Секьюрити МетаСтока.
7. Начать вывод по бумаге
8. Подождать несколько минут и убедиться, что Волатильность в МетаСток выводится с ошибкой (т.е. с округлением).
Очевидно, что Секьюрити МетаСтока осталось прежним, т.к. мы его вообще не трогали, а меняли только Инструменты в Квике, тем не менее ошибка появляется.

Я выслал Вам скриншот отражающий результат описанных выше действий. Уверен, вы Сами можете воспроизвести это на своем компьютере с тем же результатом.

Я не проверял все опционы на предмет данной ошибки и не знаю полный список ошибочных, но наиболее популярные и ликвидные выводятся с ошибкой - их я указал (Si, RI, LK, GZ).

Как Вы просили, я создавал  текстовый файл quik_metastock.log, в него все данные выводятся без ошибки, т.е. без округления, вне зависимости от вида опциона (если это необходимо, я могу его выслать). Однако, как мы видим по описанному выше, ошибка все-таки на стороне Квика, а не МетаСтока.
Ошибка при выводе волатильности в МетаСток, Данные в Метесток выводятся некорректно
 
При выводе волатильности из Квика в метасток, в последний поступают только округленные целочисленные значения, тогда как волатильность расчитывается с точностью до 3-го знака после запятой.Работать с такими данными затруднительно.
Может быть существуют какие-то настройки? Я их не нашел, брокер подсказать не смог.
Более 4-х лет назад я уже поднимал эту тему на данном форуме ссылка: http://forum-archive.quik.ru/forum/iwr/67940/68021/ , высылал скриншоты графиков из Квика и Метастока, однако ошибка как была, так и осталась!
Неужели ничего нельзя сделать?
ВНИМАНИЕ! Новая версия Quik 6.17.1.17 практически не работоспособна при передаче данных по ODBC, Резкое замедление работы версия Quik 6.17.1.17 при передаче данных по ODBC
 
Данные по ODBC заливаются в базу. Более того, я даже не понимаю как можно данные по ODBC заливать непосредственно в робота?  Или Вы имеете ввиду что-то другое? Не могли бы Вы уточнить что именно?
ВНИМАНИЕ! Новая версия Quik 6.17.1.17 практически не работоспособна при передаче данных по ODBC, Резкое замедление работы версия Quik 6.17.1.17 при передаче данных по ODBC
 
Нет, логирование "случайно" не включилось
ВНИМАНИЕ! Новая версия Quik 6.17.1.17 практически не работоспособна при передаче данных по ODBC, Резкое замедление работы версия Quik 6.17.1.17 при передаче данных по ODBC
 
Извините, а как это сделать?
Я открыл настройки своего алиаса через ODBC Data Soursce Administrator, но не нашел там никаких настроек логирования. Может я где-то не там смотрю?
ВНИМАНИЕ! Новая версия Quik 6.17.1.17 практически не работоспособна при передаче данных по ODBC, Резкое замедление работы версия Quik 6.17.1.17 при передаче данных по ODBC
 
Отправил, если что-то не так или надо еще что-то - напишите.
Страницы: 1 2 След.
Наверх