Пересматриваю свой код n-летней давности. Улыбнулся в первых шагов - функция TRANS2QUIK_CONNECT.
lpstrErrorMessage Тип: указатель на переменную типа Строка. В случае возникновения ошибки может получать сообщение о возникшей ошибке dwErrorMessageSize Тип: Long. Содержит длину строки, на которую ссылается указатель lpstrErrorMessage
На какой размер сообщений следует ориентирвоваться? Уже и Quik имеет довольно достойную версию 7.16..., а дока все в детский сад ходит. В другой теме задавал вопрос на аналогичную тему - месяц прошел... Quik еще поддерживается? Планируется его дальнейшее развитие? Roadmap есть или стагнация, и мы обречены жить с такой докой?
TRANS2QUIK_CONNECT вдруг вернул TRANS2QUIK_FAILED и pnExtendedErrorCode = 233 с сообщением lpstrErrorMessage = Connection failed at step 4 with error 233. Документация говорит: TRANS2QUIK_FAILED – произошла ошибка при установлении соединения, в pnExtendedErrorCode в этом случае передается дополнительный код ошибки. Каким образом понять, что значит код 233? Документация должна предоставить понятное описание расширенных кодов. Сообщения API, которое видят пользователи, т.е. мы, должно содержать понятный текст, а мы тут видим, что должного внимания сообщениям разработчики не уделили.
При экспорте данных по ODBC, например, стакана, со стороны БД вижу массу выражений, например:
Код
UPD ATE X.ORDERS SE T VOLUME=15.00000000 WHERE SYMBOL='SiU6' AND OP='BUY' AND PRICE=65306.000000
где значения идут непосредственно в SQL-выражении. В результате база кеширует десятки тысяч выражений. Подобные действия следует выполныть с использованием bind-переменных. Первый класс: Binding Parameters ODBC Кроме того, курсоры закрываются видимо средствами самого ODBC-драйвера. Один драйвер с этим справляется, а другой сам не закрывает и захлебывается при достижении разрешенного количества открытых курсоров (SQLSTATE=S1000).