Ошибка работы .Net business connector при выборке заказов на продажу

[DaxDeveloper]

Добрый день, коллеги!

При выполнении запроса из стороннего приложения через .net business connector получаю такую ошибку:

Microsoft.Dynamics.BusinessConnectorNet.XppException: Невозможно выбрать запись в Заказы на продажу (SalesTable).
Из базы данных выбрано нулевое значение (NULL), которое не поддерживается.
at Microsoft.Dynamics.BusinessConnectorNet.Axapta.CallStaticClassMethod(String className, String methodName, Object param1)
at DynamicsWebService2012.BCProxyAxapta2012.CallStaticClassMethod(String className, String methodName, String param)
В Аксапте логика отрабатывает нормально.

Опытным путем установили, что ошибка валится на методе find() для определенных заказов на продажу.

Ошибка также может генерироваться в конструкциях while select, в попытке получения заказов через запрос (метод queryRun.next())

Подскажите, пожалуйста, как с этим бороться?

Та же самая логика из аксапты отрабатывает нормально, ошибок синхронизации данных нет. Проблемные заказы (таких примерно около 1% от общего количества заказов) ничем особым не отличаются от остальных, полей со значениями NULL не обнаружено.

Дополнительная информация: MS DAX 2012 R3 (Версия приложения 6.3.164.0), MS SQL Server 2012.

[dech]

БД Аксапты не содержит значения null за исключением "больших" полей типа container. Для начала, убедитесь, что стороннее приложение в принципе находит запись, затем проверьте container-поля на наличие данных. В случае чего надо вести отладку стороннего приложения при наличии такой возможности.

[DaxDeveloper]

Исключение вызывается даже в отладочном методе, содержащем код:

select RecId from salesTable
  where salesTable.RecId == problemSalesRecId;

Где problemSalesRecId - RecId проблемного заказа. По идее мы не выбираем null-значения, но ошибка воспроизводится.

[fed]

Quote:

Originally Posted by DaxDeveloper

Исключение вызывается даже в отладочном методе, содержащем код:

select RecId from salesTable
  where salesTable.RecId == problemSalesRecId;

Где problemSalesRecId - RecId проблемного заказа. По идее мы не выбираем null-значения, но ошибка воспроизводится.

А попробуйте перед этим вызовом поставить salesTable.disableCache(true). Просто есть шансы что это какие-то странные глюки кэширования. То есть - из таблицы вытаскиваются корректные данные, но где-то по пути между БД, кэшем и приложением, часть полей заменяется мусором.

[DaxDeveloper]

Денис, спасибо.

salesTable.disableCache(true);

Это помогло. Думал обратить внимание в сторону кэша, но смутил момент, что даже после рестарта AOS-а проблема оставалась.
Денис, еще вопрос.
Как отключить кэширование в запросах (Query)? Сходу не нашел...

[fed]

Quote:

Originally Posted by DaxDeveloper

Денис, еще вопрос.
Как отключить кэширование в запросах (Query)? Сходу не нашел...

Не знаю такого способа, к сожалению.
Вообще я бы посоветовал просто всю проблемную логику перетащить на сервер (в смысле - поставить у классов RunOn=Server и server перед static-методами). Просто .net BC вообще мало кто пользуется. Из за этого там много не выловленых багов, которые просто некому было в MS отрепортить. А серверная компонента используется очень активно, соответственно - баги там исправлены.

Можно еще побаловаться с cross company query. Насколько я помню, кэширование работает если в списке компаний для запроса указана только одна компания. Так что можно попробовать указать реальную компанию+dat. Но вообще, эти самые cross company query временами тормозят, так что лекарство может оказаться хуже болезни...

[Raven Melancholic]

Quote:

Originally Posted by DaxDeveloper

Как отключить кэширование в запросах (Query)? Сходу не нашел...

У QueryRun есть метод setCursor(...). То есть можно объявить курсоры нужных таблиц, настроить параметры этих курсоров и подсунуть их в QueryRun перед запуском выборки queryRun.moveNext(). Не пробовал устанавливать у таких курсоров disableCache, но несколько других свойств таким образом подхватывались.

[dech]

А если просто кэш почистить? Чтобы аксапта null вернула нужно сильно постараться. Налицо видна переделка таблицы, скорее всего изменения связаны с контейнерным полем, например каким-то образом сменили id, либо меняли тип, а id остался прежним. Очистка кэша на всех клинтах поможет справиться с проблемой. И не надо ничего воротить лишнего.

[DaxDeveloper]

Коллеги, помог перевод выполнения классов на стороне сервера.
Всем огромное спасибо за помощь, особенно Денису )
Вопрос закрыт.