TempDB для SSRS

[kitty]

Есть много данных и отчет по ним.
Отчет отваливается по тайм-ауту.

В данный момент таблица, используемая DS отчета имеет тип InMemory.

1) Хочу изменить тип таблицы на TempDB, но наткнулась на статью:

https://axfactory.wordpress.com/2013...-ssrs-reports/
Действительно все так жестко кэшируется, что дынные неправильные в отчете показываются?
(+ У меня вообще вызывает большие сомнения потенциальная работоспособность описанного решения. )

2) Достаточно ли просто поменять тип таблицы на InMemory, чтобы оптимизировать выполнения отчета на большом объеме данных или нужно еще что-то менять?
(об оптимизации самих выброк тут не упоминаю)

3) В инете полно ссылок на то, как ускорить выполнение отчета в R3 с помощью класса SrsReportDataProviderPreProcessTempDB . У нас R2, но класс уже есть в наличии .... Стоит ли его использовать?

Поделитесь опытом. Спасибо.

[DSPIC]

Точно по таймауту?
Проблема больших данных давно решена в классом SrsReportDataProviderPreProcess (если ниего не путаю. Как раз TempDB\InMamory не канали). См. пример отчета \Classes\PurchPurchaseOrderDP, или любой другой отчет *FormLetter. Идея в использовании перманентных таблиц как временных - т.е. перед перчатью таблицы заполняются, после отображения удуляются. Вроде проблем не было.

[skuull]

Цитата:

Сообщение от kitty

3) В инете полно ссылок на то, как ускорить выполнение отчета в R3 с помощью класса SrsReportDataProviderPreProcessTempDB . У нас R2, но класс уже есть в наличии .... Стоит ли его использовать?

Поделитесь опытом. Спасибо.

Его как раз добавили в R2 для улучшения производительности обычных PreProcess.
http://blogs.msdn.com/b/axperf/archi...es-part-6.aspx

Мы его часто используемые для отчетов которые отваливается по таймауту да и есть парочку стандартных основаных на нем, никаких проблем с кешем замечено никогда небыло.

Старые отчеты переделывать очень легко. Достаточно поменять родителя, таблицу сделать TempDB и в начале processReport вызвать takeOwnershipOfTempTable()

[DSPIC]

Цитата:

Сообщение от 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.

А он точно в R2 работает?

[skuull]

Цитата:

Сообщение от DSPIC

А он точно в R2 работает?

Нет Только в R3, где-то я что-то перепутал. В R2 есть SrsReportDataProviderPreProcess

[kitty]

Цитата:

Сообщение от skuull

Нет Только в R3, где-то я что-то перепутал. В R2 есть SrsReportDataProviderPreProcess

точно напутали? сам класс-то SrsReportDataProviderPreProcessTempDB как раз есть и в R2 ...

[skuull]

Цитата:

Сообщение от kitty

точно напутали? сам класс-то SrsReportDataProviderPreProcessTempDB как раз есть и в R2 ...

Нет Просто нет под рукой R2 чтобы проверить. Но судя по тому что есть KB 2858835
для R2 для этого класса то значит R2 !

[kitty]

Есть недопонимание
1) В R2 есть метод takeOwnershipOfTempTable, но по перекрестным ссылкам не вижу, чтобы его хоть один наследник вызывал ...
2) В примере с TaxListDP , который они приводят по ссылке, все еще зачем-то используется

 taxListTaxTransTmp.setConnection(this.parmUserConnection());

. Хотя, в других классах-наследниках от SrsReportDataProviderPreProcessTempDB setConnection не вызывается. Таблица TaxListTaxTransTmp при этом уже TempDB. Забыли строку кода удалить, что ли?
3) Все эти временные TempDB таблицы , используемые в отчетах,зачем-то еще имеют свойство saveDataPerCompany = no. Зачем? На случай, что один и тот же пользователь в одной сессии с разными компаниями работает и один и тот же отчет вызывает?
(по приведенной ссылке не указано, что нужно это делать. Может, это в R3 просто уже не нужно, тк ядро правильно чистит таблицу)

[DSPIC]

Цитата:

Сообщение от kitty

Есть недопонимание
1) В R2 есть метод takeOwnershipOfTempTable, но по перекрестным ссылкам не вижу, чтобы его хоть один наследник вызывал ...
2) В примере с TaxListDP , который они приводят по ссылке, все еще зачем-то используется

 taxListTaxTransTmp.setConnection(this.parmUserConnection());

. Хотя, в других классах-наследниках от SrsReportDataProviderPreProcessTempDB setConnection не вызывается. Таблица TaxListTaxTransTmp при этом уже TempDB. Забыли строку кода удалить, что ли?
3) Все эти временные TempDB таблицы , используемые в отчетах,зачем-то еще имеют свойство saveDataPerCompany = no. Зачем? На случай, что один и тот же пользователь в одной сессии с разными компаниями работает и один и тот же отчет вызывает?
(по приведенной ссылке не указано, что нужно это делать. Может, это в R3 просто уже не нужно, тк ядро правильно чистит таблицу)

Видимо настал тот момент, когда стоит проверить на практики и рассказать. Вероятно, фичу начали реализовывать в R2, но не успели завершить, закончили в R3. Отсюда, какие-то куски есть, но в R2 они могут не работать.

[Denicce]

Добрый день!
Есть опыт использования класса SrsReportDataProviderPreProcessTempDB в отчетах, которые запускаются на Портале?

Создан Web control, который хостит ССРС через <dynamics:AxReportViewer runat="server" ID="ReportId" MenuItemName="ReportMenuItem" />.

Отчет в Ах работает корректно, препроцессинг отрабатывает. Но на портале работает только в том случае, если DP класс является наследником SRSReportDataProviderBase; если наследник от SrsReportDataProviderPreProcessTempDB, то выполнение отчета на портале зависает и отваливается по таймауту. Данных на выходе немного.

Пытался найти штатные отчеты, которые хостятся аналогично и используют этот класс - ни один не нашелся.

Гугл ответов не дал.

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

[Logger]

up-ну тему.

Есть ли способы вывести в ролевой центр Preprocessed отчет?

Тут пишут что невозможно.
https://community.dynamics.com/ax/f/...-while-opening

[Logger]

По поводу таймаутов попалась хорошая ссылка
https://docs.microsoft.com/en-us/arc...ssion-timeouts
пусть тут полежит.