08.01.2016, 17:41 | #1 |
Участник
|
TempDB для SSRS
Есть много данных и отчет по ним.
Отчет отваливается по тайм-ауту. В данный момент таблица, используемая DS отчета имеет тип InMemory. 1) Хочу изменить тип таблицы на TempDB, но наткнулась на статью: https://axfactory.wordpress.com/2013...-ssrs-reports/ Действительно все так жестко кэшируется, что дынные неправильные в отчете показываются? (+ У меня вообще вызывает большие сомнения потенциальная работоспособность описанного решения. ) 2) Достаточно ли просто поменять тип таблицы на InMemory, чтобы оптимизировать выполнения отчета на большом объеме данных или нужно еще что-то менять? (об оптимизации самих выброк тут не упоминаю) 3) В инете полно ссылок на то, как ускорить выполнение отчета в R3 с помощью класса SrsReportDataProviderPreProcessTempDB . У нас R2, но класс уже есть в наличии .... Стоит ли его использовать? Поделитесь опытом. Спасибо. |
|
08.01.2016, 19:59 | #2 |
Боец
|
Точно по таймауту?
Проблема больших данных давно решена в классом SrsReportDataProviderPreProcess (если ниего не путаю. Как раз TempDB\InMamory не канали). См. пример отчета \Classes\PurchPurchaseOrderDP, или любой другой отчет *FormLetter. Идея в использовании перманентных таблиц как временных - т.е. перед перчатью таблицы заполняются, после отображения удуляются. Вроде проблем не было. |
|
|
За это сообщение автора поблагодарили: Logger (1), kitty (1). |
08.01.2016, 20:50 | #3 |
Участник
|
Цитата:
http://blogs.msdn.com/b/axperf/archi...es-part-6.aspx Мы его часто используемые для отчетов которые отваливается по таймауту да и есть парочку стандартных основаных на нем, никаких проблем с кешем замечено никогда небыло. Старые отчеты переделывать очень легко. Достаточно поменять родителя, таблицу сделать TempDB и в начале processReport вызвать takeOwnershipOfTempTable() |
|
|
За это сообщение автора поблагодарили: kitty (1), gl00mie (2). |
08.01.2016, 22:01 | #4 |
Боец
|
Цитата:
Сообщение от skuull
Его как раз добавили в R2 для улучшения производительности обычных PreProcess.
http://blogs.msdn.com/b/axperf/archi...es-part-6.aspx Мы его часто используемые для отчетов которые отваливается по таймауту да и есть парочку стандартных основаных на нем, никаких проблем с кешем замечено никогда небыло. Старые отчеты переделывать очень легко. Достаточно поменять родителя, таблицу сделать TempDB и в начале processReport вызвать takeOwnershipOfTempTable() Цитата:
This R3 feature is implemented in the kernel.
|
|
09.01.2016, 01:34 | #5 |
Участник
|
|
|
09.01.2016, 04:45 | #6 |
Участник
|
|
|
09.01.2016, 08:41 | #7 |
Участник
|
|
|
11.01.2016, 12:58 | #8 |
Участник
|
Есть недопонимание
1) В R2 есть метод takeOwnershipOfTempTable, но по перекрестным ссылкам не вижу, чтобы его хоть один наследник вызывал ... 2) В примере с TaxListDP , который они приводят по ссылке, все еще зачем-то используется X++: taxListTaxTransTmp.setConnection(this.parmUserConnection()); 3) Все эти временные TempDB таблицы , используемые в отчетах,зачем-то еще имеют свойство saveDataPerCompany = no. Зачем? На случай, что один и тот же пользователь в одной сессии с разными компаниями работает и один и тот же отчет вызывает? (по приведенной ссылке не указано, что нужно это делать. Может, это в R3 просто уже не нужно, тк ядро правильно чистит таблицу) Последний раз редактировалось kitty; 11.01.2016 в 13:20. |
|
11.01.2016, 17:42 | #9 |
Боец
|
Цитата:
Сообщение от kitty
Есть недопонимание
1) В R2 есть метод takeOwnershipOfTempTable, но по перекрестным ссылкам не вижу, чтобы его хоть один наследник вызывал ... 2) В примере с TaxListDP , который они приводят по ссылке, все еще зачем-то используется X++: taxListTaxTransTmp.setConnection(this.parmUserConnection()); 3) Все эти временные TempDB таблицы , используемые в отчетах,зачем-то еще имеют свойство saveDataPerCompany = no. Зачем? На случай, что один и тот же пользователь в одной сессии с разными компаниями работает и один и тот же отчет вызывает? (по приведенной ссылке не указано, что нужно это делать. Может, это в R3 просто уже не нужно, тк ядро правильно чистит таблицу) |
|
10.03.2016, 14:48 | #10 |
Участник
|
Добрый день!
Есть опыт использования класса SrsReportDataProviderPreProcessTempDB в отчетах, которые запускаются на Портале? Создан Web control, который хостит ССРС через <dynamics:AxReportViewer runat="server" ID="ReportId" MenuItemName="ReportMenuItem" />. Отчет в Ах работает корректно, препроцессинг отрабатывает. Но на портале работает только в том случае, если DP класс является наследником SRSReportDataProviderBase; если наследник от SrsReportDataProviderPreProcessTempDB, то выполнение отчета на портале зависает и отваливается по таймауту. Данных на выходе немного. Пытался найти штатные отчеты, которые хостятся аналогично и используют этот класс - ни один не нашелся. Гугл ответов не дал. Изначальная идея заключалась не столько в скорости, сколько в возможности управлять процессом сборки данных, т.е. использовать при необходимости инфо и исключения. Если DP наследник от Base, то ни инфо, ни исключения не работают (инфо тупо игнорируются, исключения вешают отчет до таймаута). При препроцессинге все ок, кроме Портала. |
|
|
За это сообщение автора поблагодарили: Logger (1). |
01.12.2020, 16:56 | #11 |
Участник
|
up-ну тему.
Есть ли способы вывести в ролевой центр Preprocessed отчет? Тут пишут что невозможно. https://community.dynamics.com/ax/f/...-while-opening |
|
01.12.2020, 16:57 | #12 |
Участник
|
По поводу таймаутов попалась хорошая ссылка
https://docs.microsoft.com/en-us/arc...ssion-timeouts пусть тут полежит. |
|
Теги |
srsreportdataproviderpreprocesstempdb, ssrs |
|
|