Опять ошибка получения кол-ва ордеров скриптом

Nikolay, поставь на реал на хотябы на пару деньков и понаблюдай.  LIMIT_KIND        = 0 почему равен 0? Если есть желание поставь посмотри, нет то нет

А где строка с первоначальным mLots = 0 ?

Далее, обратите внимание на эту строку
Почему вдруг TotalLots стал integer в то время, как getDepoEx возвращает currentbal во float?

Напрашивается вывод:

Nikolay, думаю даже можно такой код поставить на реал, он просто будет брать данные с реального счета, но делать то ничего не будет( кроме как брать данные и караулить баг) и мешать основному торговому роботу, если всплывет ошибка то засимафорит. Но это по желанию.


SEC_CODE          = 'SBER'
CLASS_CODE        = 'QJSIM'
ACCOUNT           = 'NL0011100043'
CLIENT_CODE       = '11609'
FIRM_ID           = 'NC0011100000'
LIMIT_KIND        = 365                  -- <<<<<<<<

mLots = 0
L=0

function main()
while true do

   local tblTotalLot =     getDepoEx(FIRM_ID, CLIENT_CODE, SEC_CODE, ACCOUNT ,LIMIT_KIND)
   if tblTotalLot==nil     then TotalLots=0    else TotalLots=tonumber(tblTotalLot.currentbal)         end

   x=  TotalLots

   if( mLots~=TotalLots ) then
       message(SEC_CODE.."   TotalLots  "..tostring(TotalLots).."   mLots   "..tostring(mLots).."   x   "..tostring(x),3 )
       mLots=TotalLots
   end


sleep(1000)
 end
end

Старатель, я не правильно пытаюсь получить значения через
  local tblTotalLot =     getDepoEx(FIRM_ID, CLIENT_CODE, SEC_CODE, ACCOUNT ,LIMIT_KIND)
  if tblTotalLot==nil     then TotalLots=0    else TotalLots=tonumber(tblTotalLot.currentbal)         end
?
Зачем мне обязательно делать перебор полей?

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

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

Код, что Вы предоставили, дает мало информации, поэтому вывод дополнительной информации дал бы больше возможностей понять в чем проблема.
Я сталкивался с особенностями работы функций get... поэтому стараюсь при анализе понимать, что сохранено в таблице к которой эта функция обращается.
Собственно unit_test этой функции так и надо написать, сравнить возвращаемое значение с эталонным в таблице.

Вы же просто пишите - функция не работает. Разработчики ответят: проверили - работает.

Подтверждаю: "косяк" есть. Но в моём случае - это когда getDepoEx ничего не возвращает для того же набора параметров (FIRM_ID, CLIENT_CODE, SEC_CODE, ACCOUNT, LIMIT_KIND)
При этом вызов getDepoEx сразу после ошибки
возвращает уже нормальную таблицу с корректными значениями.

Ситуаций с левым currentbal не встречалось.

Старатель, ну вот уже что то, если еще и мой скрипт запустить и оставить поработать то можно и разные циферки получить, что может привести к продаже/покупке( в зависимости от ситуации), а потом к обратной покупке/продаже)

седня прям с утра поймался баг :

FOLD_SPB   date - time  Wed Jun  2 09:34:10 2021   TotalLots  1.0   memoryLots   2.0
FOLD_SPB   date - time  Wed Jun  2 09:34:11 2021   TotalLots  2.0   memoryLots   1.0

из кода убрал еще одну переменную x,  как видно не в этом дело

SEC_CODE          = ???????????              
CLASS_CODE        =???????????              
CURR_CODE         =???????????              
ACCOUNT           = ???????????          
CLIENT_CODE       =???????????              
TAG               =???????????    
FIRM_ID           =???????????      
LIMIT_KIND        = 365                    

memoryLots = 0 -- сюда запоминаем кол-во лотов полученных из терминала, если не равно TotalLots и не было сделок то...

function main()
while true do

  local tblTotalLot =     getDepoEx(FIRM_ID, CLIENT_CODE, SEC_CODE, ACCOUNT ,LIMIT_KIND)
  if tblTotalLot==nil     then TotalLots=0    else TotalLots=tonumber(tblTotalLot.currentbal)         end

  if( memoryLots~=TotalLots ) then
      message(SEC_CODE.."   date - time  "..tostring(os.date()).."   TotalLots  "..tostring(TotalLots).."   memoryLots   "..tostring(memoryLots),3 )
      memoryLots=TotalLots
  end

sleep(1000)
end
end

Добрый день.

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

 74 сообщения и нигде не указана версия QUIK, в которой запускается программа в которой происходит непонятное. Версию QUIK следует указывать обязательно.
     Если вы работаете с QUIK версии >= 8.5 и < 8.13.1.16, то в них есть ошибка синхронизации, которая может проявляться в виде сбоев (смотрите ветку Отладка QUIK 8.13 ...).

  Где вы взяли версию 8.13.3.1, если последняя официальная версия на сайте ARQA  8.13.1 (8.13.1.16) от 19.04.21?

TGB, вы вообще имеете отношение к разработчикам или как я пользователь?

TGB,
Между этими версиями наверное десятиление и в них есть ошибка синхронизации, которая может проявляться в виде сбоев ( и приводить к потере денег клиентов ), это вообще как, нормально???!!! Это все равно, что продавать самовозгарающиеся авто.

Артем, критикуешь меня и пишешь, что критиковать людей Действительно Буду теперь помалкивать)

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

Сирануш, ну и по теме топика хотел бы добавить немного мыслей.
Я бы дополнительно через коллбек OnDepoLimit попытался точнее определить проблему.
Смотрите зачем это надо.
Если через коллбек будут прилетать расхождения, тогда проблема не в квике, а в брокере, который шлет левые данные.
Либо же через коллбек расхождений не будет наблюдаться, а через функцию getDepoEx будут расхождения, тогда косяк явно квика.

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

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

Скрипт в 71 посте есть, только вместо вопросов вставить нужные значения. Там же есть проблема отражена, то что выводится в сообщении. Не думаю, что я смогу за секунду все это проделать пока значения вернуться в правильное состояние. У вас нет такой проблемы или вы не запускали?

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

------------
-----------------------------
 Выше приведенные комментарии, скорее всего, означают, что функция getDepoEx не является потокобезопасной. Вообще, все функции API работы с QUIK из QLua должны быть потокобезопасными  хотя бы из-за того, что к ним могут обращаться из нескольких одновременно запущенных скриптов (работающих в разных потоках). Причем, ! обращаю особое внимание разработчиков, что объекты синхронизации в таких функциях должны локализоваться в месте, общем для всех скриптов, и это место точно не global_State и тем более не lua_State.
----
  Просьба к поддержке, довести данный комментарий до разработчиков QUIK.

На самом деле, хотелось бы обратиться к читающим эту ветку, чтобы вы запустили у себя код( заменив вопросики на соответсвующие значеиния) из 71 поста и если подобное всплывет отписали сюда.

Эта проблема легко воспроизводится скриптом, опубликованном мной в сообщении #59

В скрипте Сирануш в том случае, если getDepoEx ничего не возвращает, присваивает значению текущего остатка ноль.
Поэтому для него "getDepoEx ничего не возвращает" = "ошибка текущего остатка", если по факту позиция открыта. Если позиция закрыта, то этой ошибки в его скрипте не будет.

Что касается левых значений в currentbal, то, вероятно, это может быть связано с открытыми позициями, их количеством, классами, сроков расчётов и пр. факторами.
Т.ч. договаривайтесь с ТС о копии рабочего места.

 Реакции поддержки на просьбу нет.
 Ее трудно выполнить? Или поддержка считает, что выше написанное, не относится к обсуждаемому в данной ветке?