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

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

Страницы: 1
Сбой передачи данных по ODBC при переходе на 19-тизначный номер заявки, Сбой передачи данных по ODBC при переходе на 19-тизначный номер заявки
 
Цитата
Юрий Балашов написал:
Цитата
Sergey Gorokhov написал:

Дополним,
Если проблема действительно в FB то обновление терминала никак не поможет.
ответ следует искать на форумах где обсуждается FB.
Еще можно попробовать изменить тип данных в самой базе.
Да, проблема действительно в FB, Квик передает данные, но усеченные, не все 19 цифр. Поэтому и был вопрос, на какой базе данных тестировали передачу данных по ODBC?
На какой тип данных изменить, в самой базе у меня стоит DOUBLE PRECISION?
Это же теперь целочисленный тип, а не вещественный, как было раньше (и всех сильно забавляло).
Правда, хелп QUIK'а (info.chm от 20.07.20) версии 8.8.4 (ftp.quik.ru//public/updates/8.8/quik_8.8.4_upd.zip от 21.08.20) все еще упорно говорит нам о том, что там decimal, да еще и с 15 знаками в целой части.

Таблица заявок

Таблица заявок
Параметр Формат
Номер DECIMAL(15,0)

Таблица сделок
Параметр Формат
Номер DECIMAL(15,0)
Заявка DECIMAL(15,0)

в BIGINT корректно пишет.
https://firebirdsql.org/refdocs/langrefupd15-bigint.html
Проверено в 3-м диалекте.
Сбой передачи данных по ODBC при переходе на 19-тизначный номер заявки, Сбой передачи данных по ODBC при переходе на 19-тизначный номер заявки
 
Цитата
Юрий Балашов написал:
Цитата
Sergey Gorokhov написал:

Дополним,
Если проблема действительно в FB то обновление терминала никак не поможет.
ответ следует искать на форумах где обсуждается FB.
Еще можно попробовать изменить тип данных в самой базе.
Да, проблема действительно в FB, Квик передает данные, но усеченные, не все 19 цифр. Поэтому и был вопрос, на какой базе данных тестировали передачу данных по ODBC?
На какой тип данных изменить, в самой базе у меня стоит DOUBLE PRECISION?

Это же теперь целочисленный тип, а не вещественный, как было раньше (и всех сильно забавляло).
Правда, хелп QUIK'а (info.chm от 20.07.20) версии 8.8.4 (ftp.quik.ru//public/updates/8.8/quik_8.8.4_upd.zip от 21.08.20) все еще упорно говорит нам о том, что там decimal, да еще и с 15 знаками в целой части.
Таблица заявок
ПараметрФормат
НомерDECIMAL(15,0)
Таблица   сделок
ПараметрФормат
НомерDECIMAL(15,0)
ЗаявкаDECIMAL(15,0)
в BIGINT корректно пишет.
https://firebirdsql.org/refdocs/langrefupd15-bigint.html
Проверено в 3-м диалекте.
Некорректный ответ Trans2Quik.dll при включенном терминале (TRANS2QUIK_DLL_NOT_CONNECTED)
 
Добрый день!

Наконец-то удалось решить проблему с подключением Trans2Quik.dll 1.2 на Windows 10 x64 (TRANS2QUIK_CONNECT возвращал "Connection failed at step 1 with error 5").

Решение навеял пост http://o-s-a.net/forum/threads/385.
В итоге, после некоторых комбинаций с разными правами, коннект нормально установился при запуске Quik в режиме совместимости с Windows 8 (в свойствах файла info.exe, вкладка "Совместимость").

Господа разработчики, вам решать, правильно это или нет, но, на мой взгляд, это некорректная реализация dll.

P.S. чистая установка (по совету Дмитрия) не помогла.
Некорректный ответ Trans2Quik.dll при включенном терминале (TRANS2QUIK_DLL_NOT_CONNECTED)
 
Добрый день, Сергей!

С версией 1.2 я разобрался еще 5 лет назад))
И модуль работы с API с тех пор не трогал.

Цитата
Sergey Gorokhov написал:
Для начала, проверьте банальные вещи:
А именно, включен ли импорт транзакций в терминале QUIK (меню Сервисы - Экспорт/Импорт данных - Внешние транзакции)?
Корректно ли указан путь к папке с терминалом QUIK в параметрах подключения? (особенно следует обратить внимание что в х64 битной системе две папки "Program Files")

Это тоже все проверил в первую очередь.

Цитата
Sergey Gorokhov написал:
Заранее отмечаем что ни у нас ни у кого-либо еще не возникало проблем с работой версии 1.2. именно из-за х64 битной ОС.

Ну это уже хоть что-то.

Спасибо. Буду копать вместе с C++.
Некорректный ответ Trans2Quik.dll при включенном терминале (TRANS2QUIK_DLL_NOT_CONNECTED)
 
Добрый день, Станислав!

Приложение корректно работает на Windows Server 2012.
И так же корректно работало на Windows XP, Windows 7, Windows 8 и Windows 10 32-й разрядности.
Как только была установлена 64-разрядная Windows 10, коннект r Quik пропал.

Я почему-то ожидал что вы знаете, какие подводные камни могут "выплыть" при переходе с x86 на x64.
Но никак не ожидал предложения "сравнить свою версию на Delphi  с нашими C++ и C#". И найти отличия...

P.S. Неправильно написал в первом сообщении.
Ошибка в TRANS2QUIK_CONNECT. На выходе - TRANS2QUIK_FAILED. pnExtendedErrorCode возвращает код 5.
Как следствие - следующая ошибка в TRANS2QUIK_IS_DLL_CONNECTED. На выходе - TRANS2QUIK_DLL_NOT_CONNECTED.

С уважением,
Сергей.
Некорректный ответ Trans2Quik.dll при включенном терминале (TRANS2QUIK_DLL_NOT_CONNECTED)
 
Добрый день!
На сервере, на 64-разрядной версии Windows 2012 R2, версия 1.2 Trans2Quik работает исправно.
На локальной машине, после перехода с 32-й на 64-ю пропал коннект.
Функция TRANS2QUIK_CONNECT теперь при включенном терминале возвращает TRANS2QUIK_DLL_NOT_CONNECTED, как при запуске в режиме отладки, так и при запуске exe-файла.
При подключении dll версии 1.3 приложение на Delphi выдает критическую ошибку – «Ошибка при запуске приложения…».
В чем может быть проблема?

ОС – Windows 10 Pro x64
QUIK – 7.14.1.7, брокер – БКС. Обработка внешних транзакций включена.
Trans2Quik.dll – 1.2.
Подмена TransId c версии сервера 5.4.2
 
Добрый день, господа разработчики!

Уточните, когда ждать решения.
Убил кучу времени на поиск этой ошибки, пока не наткнулся на этот пост.
В итоге - что, move_orders юзать теперь нельзя? Делать по-колхозному, через снятие старой и отправку новой?

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

Все получилось.
Заявка на вывод денег через API, Не получается создать заявку на вывод денег через API
 
Добрый день, Сергей!

Спасибо.
Никогда бы не подумал, что так можно.

Тем не менее.
Отправляю транзакцию, аналогично взятой из кармана (странно, что на русском):

Код торгового счета=L01-00000F00; Примечание=00000; ACTION=Вывод денег; TRANS_ID=123456; Инструмент=RURFORTS; Режим=TRANOUT; Тип вывода=Безналично; Сумма=11; Снять весь остаток=Нет; Срочный вывод=Нет;

Выдает ответ "не указан режим".

Все ли верно делаю?

С уважением,
Сергей.
Заявка на вывод денег через API, Не получается создать заявку на вывод денег через API
 
Добрый день!

Уважаемые разработчики, проясните, можно ли создать транзакцию на вывод денег через API?

Пробовал и так:

CLIENT_CODE=ХХХХХ; ACCOUNT=ХХХ-ХХХХХХХХ; ACTION=NEW_ORDER; TRANS_ID=123456; CLASSCODE=TRANOUT; SECCODE=RURFORTS; QUANTITY=10000

и так:

CLIENT_CODE=ХХХХХ; ACCOUNT=ХХХ-ХХХХХХХХ; ACTION=NEW_ORDER; TRANS_ID=123456; CLASSCODE=TRANOUT; SECCODE=RURFORTS; PRICE=10000

Вместо ХХХХХ и ХХХ-ХХХХХХХХ - конечно, реальные код клиента и счет.

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

Руками (из терминала) созданная транзакция тоже не помогла: в таблице транзакций она отображена не полностью - ни в одном из столбцов нет значения суммы. И какой ACTION должен быть - тоже загадка.


С уважением,
Сергей.
Медленный экспорт в Firebird через ODBC
 
Добрый день, Олег!

Проблема решена. По крайней мере, устранены сильные тормоза и скорость работы доведена хотя бы до скорости Access'а.

Как выяснилось, мой виртуальный хостер предоставляет SSD-диски только для системного раздела. А доп.раздел - SATA.
Сам FB, БД и каталог для временных файлов перенесены на SSD-диск. Теперь экспорт тех же данных занимает не 120 сек, а только 3-4 сек. Что в целом уже почти устраивает.

+ немного подкрутил настройки firebird.conf.
Осталось еще памяти добавить.

Помогла статья http://www.ibase.ru/devinfo/optimize.htm.

С уважением,
Сергей.
Медленный экспорт в Firebird через ODBC
 
Добрый день, Олег!

По уменьшению интервала обновления - понятно. Увеличил. Спасибо.

Но остались вопросы:

1. Почему экспорт тех же данных в Access (тоже через тормозной ODBC) производится быстрее в 50-60 раз (1500 строк: 2 минуты в FB против 2 сек в Access)? Неужели он шустрее FB?

2. Как посоветуете повысить производительность FB? Может, проблема в драйвере? Какие есть альтернативы?


С уважением,
Сергей.
Некорректная отработка экспорта через ODBC
 
Добрый день, Сергей!

Вы пишите:
Уникальность записи контролируется не QUIK, а самой базой данных через первичные ключи или индексы уникальности.
Соответственно если они не настроены, то очередная запись добавляется, а не обновляется.

А в этом сообщении https://forum.quik.ru/messages/forum11/message4956/topic546/#message4956 я написал, что при наличии уникальных индексов выдается ошибка, и обновление не производится.

Поясните, в каких тогда случаях работает обновление, а не добавление, и что настроил некорректно.
Еще раз повторюсь, что удалять все данные, а потом добавлять новые - на мой взгляд, нерационально, да и БД быстрее растет.


С уважением,
Сергей.
Медленный экспорт в Firebird через ODBC
 
Прошу прощения.
* Олег.
Медленный экспорт в Firebird через ODBC
 
Добрый день, Сергей!

Логи отправил.
Спасибо.

С уважением,
Сергей.
Некорректная отработка экспорта через ODBC
 
Сергей,

я не знаю синтаксис ODBC.
А нем нет ничего подобного команде "update or ins ert in to..."?

С уважением,
Сергей.
Некорректная отработка экспорта через ODBC
 
Добрый день, Сергей!

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

Но, если настроить индексы, например, в таблице параметров (уникальный индекс по полю, в которое вносятся значения поля "Инструмент *"), то при импорте через ODBC (когда значения уже вставлены, и необходимо сделать апдейт):

В MS Access выводится сообщение:

[Microsoft][Драйвер ODBC Microsoft Access] Изменения не были успешно внесены из-за повторяющихся значений в индексе, ключевых полях или связях.  Измените данные в поле или полях, содержащих повторяющиеся значения, удалите индекс или переопределите его, чтобы разрешить повторяющиеся значения, и повторите попытку.
SQLSTATE=23000
Код ошибки=-1605

А при экспорте в FireBird:

[ODBC Firebird Driver][Firebird]violation of PRIMARY or UNIQUE KEY constraint "INTEG_2" on table "QUIKPARAMS"
Problematic key value is ("TICKER" = 'Si34000BR5')
SQLSTATE=23000
Код ошибки=-803



С уважением,
Сергей.
Некорректная отработка экспорта через ODBC
 
Добрый день!

В разделе "Использование ODBC для экспорта информации" справки QUIK в описании параметров написано:
  • «Чистить таблицу перед выводом» - если флажок установлен, то перед началом экспорта, при смене сессии, сервера или пользователя старые данные из таблицы будут удалены; если флажок снят, то новые данные будут замещать старые по мере поступления.
Но, в действительности, режим "обновления", в принципе, не работает. Если снять галку, то строки добавляются повторно. Причем не только измененные, а все.

Проверял на разных таблицах. Везде все одинаково. Индексов уникальности в таблицах нет.

Приходится использовать режим полного чистки перед записью. В таком случае размер базы растет очень быстро.

Прошу пояснить, в чем смысл такого режима обновления. Если это все-таки ошибка (причем - ей уже много лет), то сообщите, когда она будет исправлена.

С уважением,
Сергей.
Медленный экспорт в Firebird через ODBC
 
Добрый день!

Экспорт из QUIK в FireBird через ODBC осуществляется с задержками.
К вечеру достигает опоздания 1-2 часа (!!!).

Экспорт осуществляется из 9 таблиц, самая большие - таблица параметров в 2 версиях:
1. Колонки: Код бумаги Бумага Бумага сокр. Баз.актив Код класса Класс Тип опциона Лот Точность Шаг цены Страйк Дата исп. Валюта Марж.
2. Колонки:  Код бумаги Спрос Предл. Теор. цена Цена послед. Волатильность БГОНП БГОП ГО покупателя ГО продавца Статус
Обычно по 300-700 строк. Опционы.
Экспорт одной таблицы в 700 строк осуществляется в течение 1-2 минут.

Проверялось с таблицам FB как с индексами, так и без них.

QUIK 6.17.1.17. Проблема была также и в предыдущих версиях (6.16.1.15, 6.16.0.42, 6.15.2.9, 6.15.1.17).
FireBird 2.5.3.26778.
FireBird ODBC Driver 2.0.3.154 (http://www.firebirdsql.org/en/odbc-driver), также проверял на 2.0.2.153, как на Windows xp, так и на Windows Server 2008 R2 Standard.

При этом, в той же сессии одновременно с FB экспорт осуществляется и в базу MS Access. Так же через ODBC. Мгновенно (700 строк за 1-2 сек), объемы данных - точно такие же.

Нашел на форуме подобную проблему в ветке http://forum-archive.quik.ru/forum/iwr/77235/
Но там проблема была решена обновлением версии QUIK'а.

Здесь, думаю, проблема в чем-то другом. Прошу помочь.

С уважением,
Сергей.
Страницы: 1
Наверх