Таблциа Истории

квик не предназначен для того, чтоб судить об изменении параметра какой-либо таблицы исходя из изменения только ОДНОЙ таблицы. Если нужен действительно безсбойный вариант - надо принимать во внимание и другие смежные таблицы. Кроме того, сама биржа частенько чудит, выдавая пользователям полный бред, а потом, мило извиняется (НО!!!! сделки не анулирует) и деньги не возвращает., а говорит, что это просто сбой, увы-с. Брокеры в тоже время, говорят тоже самое: - это биржа, детка и что, мы должны учитывать риски.

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

Это надо понимать так, что когда речь идет о получении значений ТТП срезами, то это касается лишь передачи данных от сервера QUIK в терминал, в то время как сам сервер QUIK получает с биржи и отслеживает абсолютно все изменения этих параметров непрерывно, а не срезами?

не может этого делать по определению.

Никто ничего не "мониторит" То есть, не существует какого-либо алгоритма определения "изменились данные" или это "предыдущее значение". Раз в период, с биржи приезжает кучка параметров. Эта кучка отправляется от сервера клиенту. Клиент в свою очередь, обновляет только те данные которые приехали, а те которые не приехали оставляет в предыдущем значении

Раз в период, с биржи приезжает кучка параметров. Эта кучка отправляется от сервера клиенту. Клиент в свою очередь, обновляет только те данные которые приехали, а те которые не приехали оставляет в предыдущем значении. раз в промежуток между срезами были изменения, то биржа отправит эту самую кучку. А то что цифры в этом изменении фактически остались те же никто не проверяет

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

Или все же биржа отправляет в этом случае только текущие (последние) значения параметров?

Из всего вышесказанного я понял, что от биржи приходят только значения параметров, по которым были зафиксированы изменения в промежутке между двумя интервалами времени (срезами).
Можно ли в таком случае добавить в функцию OnParam(STRING class_code, STRING sec_code) еще один параметр, сообщающий, изменение значений каких именно параметров ТТП привело к вызову этой функции?
Ведь в противном случае нам приходится лишний раз вызывать функцию getParamEx для получения значений каждого интересующего нас параметра и последующего анализа их значений. В итоге может оказаться, что интересующие нас параметры не изменились, но мы проделали в скрипте кучу ненужной работы и тем самым создали лишнюю нагрузку на систему.

А пока данное пожелание не реализовано, разумно ли вместо OnParam использовать функции CreateDataSource и SetUpdateCallback на каждый из отслеживаемых параметров? Не окажет ли это негативного влияния на производительность?

Неправильное предположение. Память дополнительнл расходоваться не будет

Тут правда надо отметить, что я использовал тиковый интервал при вызове функции CreateDataSource.

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

Такой который даст Вам исчерпывающую информацию для анализа.

речь идет про SetUpdateCallback.
Для него интервал не имеет значения (не считая тикового).
Поэтому и ответ "на свое усмотрение"

Тиковые данные, это по сути Таблица Всех Сделок только в виде графика, а интервальные данные это уже сжатая информация с сервера. От сюда возникает гигантская разница в количестве. Интервальных данных может быть максимум 60*24+3000=4440, а тиковых неограниченное количество. Из за этого при работе с тиковыми данными могут быть тормоза

Видимо, число минут в часе и торговых часов в сутках (если бы торги шли круглосуточно).

Добрый день,

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

не совсем понял, о каком именно вопросе идет речь?

так не должно быть. Приведите пример исследований

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

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

нет, разные.