|
![]() |
#1 |
Участник
|
Исключение вызывается даже в отладочном методе, содержащем код:
X++: select RecId from salesTable where salesTable.RecId == problemSalesRecId; |
|
![]() |
#2 |
Moderator
|
А попробуйте перед этим вызовом поставить salesTable.disableCache(true). Просто есть шансы что это какие-то странные глюки кэширования. То есть - из таблицы вытаскиваются корректные данные, но где-то по пути между БД, кэшем и приложением, часть полей заменяется мусором.
|
|
|
За это сообщение автора поблагодарили: DaxDeveloper (1). |
![]() |
#3 |
Участник
|
Денис, спасибо.
X++: salesTable.disableCache(true); Денис, еще вопрос. Как отключить кэширование в запросах (Query)? Сходу не нашел... |
|
![]() |
#4 |
Moderator
|
Цитата:
Вообще я бы посоветовал просто всю проблемную логику перетащить на сервер (в смысле - поставить у классов RunOn=Server и server перед static-методами). Просто .net BC вообще мало кто пользуется. Из за этого там много не выловленых багов, которые просто некому было в MS отрепортить. А серверная компонента используется очень активно, соответственно - баги там исправлены. Можно еще побаловаться с cross company query. Насколько я помню, кэширование работает если в списке компаний для запроса указана только одна компания. Так что можно попробовать указать реальную компанию+dat. Но вообще, эти самые cross company query временами тормозят, так что лекарство может оказаться хуже болезни... |
|
|
За это сообщение автора поблагодарили: sukhanchik (2), alex55 (3). |
![]() |
#5 |
Участник
|
У QueryRun есть метод setCursor(...). То есть можно объявить курсоры нужных таблиц, настроить параметры этих курсоров и подсунуть их в QueryRun перед запуском выборки queryRun.moveNext(). Не пробовал устанавливать у таких курсоров disableCache, но несколько других свойств таким образом подхватывались.
|
|
|
За это сообщение автора поблагодарили: sukhanchik (2). |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|