I have a few shared datasets on which I have enabled caching on in Report Manager (SSRS 2008 R2). They are used to populate parameter values, and need to be refreshed on the first of each month. I am attempting to create a Cache Refresh Plan through the Shared Dataset > Manage > Cache Refresh Options. After creating the refresh plan, clicking OK, and clicking OK once again under 'Refresh the cache according to the following schedule:,' I am prompted with the following error message:
An attempt has been made to use an event type 'RefreshCache' that is not registered with this report server for external use. (rsUnknownEventType)'"
Is anyone familiar with this error and of a way to bypass it? Although I could simply allow the cache to expire on the 1st of each month, I do not want to burden the end-user with wait times during which a new cache is being built on the first run on the first of each month.
I should also mention that I am not assigned the System Administrator role on the Report Manager. I'm just a lowly Content Manager.
Related
I'm having issues with one of my reports timing out when certain parameters are passed to it. This seems to happen when the execution of the stored procedure (that builds the dataset for the report) runs over 2 mins.
I have ran the query within SSMS and the query runs and finishes in 2 mins 5 seconds.
I have read up on numerous ways on trying to increase this time out value:
Updating the report on the web portal to run indefinitely.
Updating the remote query timeout for the db instance (set to 600s)
Updating DatabaseQueryTimeout in rsreportserver.config (set to 360s)
Updated Httpruntime, executionTimeout property in web.config (set to 9000s)
Moving back through the chain I have found that the issue persists when running the report directly from the SSRS web portal.
When you inspect the console on the site, I get the following:
Funnily enough if i hit view report again after hitting this error the report is correctly generated. guessing this is because the query data was cached?
Was wondering if anyone has experienced this and would be able to give me guidance on a setting / configuration which would stop the timeout.
The version of SSRS is 2016
I'm just helping out while our regular SSRS guy is away and having an issue.
There is currently a very large report that's being generated. The subscription settings for this report is to ftp the report. The Subscription status for the report currently says "Processing delivery...". I assume this to mean that it finished generating and is now trying to send the file to the ftp location. I can see that the file is there in the ftp folder but the size is still 0kb. It has been saying "Processing delivery..." for a long time now.
My question is: Is there a location (folder or sql table) I can check to see if ssrs is actually doing something? I assume it would create temporary file somewhere locally first before sending it on its way.
Check the ExecutionLog views in the ReportServer DB of your SQL Instance. There are three views which show everything from the requested format to start time, complete times, and parameters used. Take a look at the time difference between start and complete for previous runs and compare it to the running time of the current report whose complete time will be null if it is still processing.
For bonus points: setup a SSRS report based on the view and set a subscription for daily email delivery. This saves a TON of time when troubleshooting reports where users can't tell you the parameters they use or the morning reports are empty, etc.
Also, funny as it sounds, you might want to check the free space on the server that the report is output to. With no free space the report will show processing delivery for a long time. If it's FTP and you don't have control of the FTP server, still might be worth the quick phone call.
Our reports in SSRS stopped sending. The last report was sent 2 days ago, and was send successfully, but since then none of the reports are being sent.
If I look at the SSRS web page for each report, there is no error. Simply showing the last run time as 2 days ago, so seems it didn't even try send.
Yesterday we did make some changes. But only moving a database from the Express version, to the regular version. We did not do anything that would affect the SSRS metadata (or at least we don't think we did...)
Where should we start looking to see why the report subscriptions stopped? Is there a process that could have accidentally been disabled? Thank you!
The Report subscriptions are created as jobs for the SQL Agent. You should see a long list of jobs with GUIDs as the names. Make sure that the SQL agent jobs are running. Going through the Steps of the SQL Reporting Services Configuration tool will recreate these jobs if you were to move the Reporting Service installation to another server. (I don't recall which step recreates the subscriptions. Just go through each pane and click "Apply.")
Depending on how you move things, you may need to backup and restore encryption keys, and you can easily end up in a state where two copies of subscription exist and are executed ( on different servers.) But in your case, where you didn't move SSRS, I'd look at the SQL Agent properties on the original server (Express) to see that the SQL agent is enabled and running, and check the history of the SQL Agent jobs, to see if there are any problems.
I created a report in SSRS, and deployed it. I went to the properties of the report the Process option, and tried to set up Cache a temporary copy of the report and got an error 'Credentials used to run this report are not stored.' I get the same error if I go to Snapshot Options and try to select any of the options there.
Thanks in advance
As per the error, you need to set up the report Data Source similar to the following:
If you're not storing credentials you cannot cache reports or create snapshots.
With cached reports, a temporary copy is created when a user runs a report and this can be used for subsequent runs of the report. Since this could be performed by different users, the only way this can work is if the same connection is used to the Data Source each time; it must be independent of whoever is running the report when the copy is cached.
Same principle for snapshots; no guarantee who will run reports based off the snapshot, so the Data Source connection must be independent of the user running the report, i.e. stored at the Data Source level.
I am new to this version of reporting services. I did some research and found off of Microsoft's website:
To set report caching options
Point to a report in the library.
Click the down arrow, and select Manage processing options.
In Data Refresh Options, click Use cached data. If you see "This report can not be cached because one or more of the data sources credentials are not stored", the report is not configured to run unattended and you must modify the data sources to use stored credentials before setting this option. For instructions, see How to: Schedule Report and Subscription Processing (Reporting Services in SharePoint Integrated Mode).
In Cache Options, specify how the cache will expire:
Enter a number of minutes after which the cache will expire.
Use a shared schedule to clear the cache at times specified in the schedule.
Create a custom schedule to clear the cache at a time that you specify.
That is all well and good if I didn't have more than a small hand full of reports to do this individually to, but I have at least 20 reports that will get installed to multiple systems so doing this manually each time is not feasible.
What I would like to find out is there a way to either script or some other way to set multiple reports with the cache option set to not cache instead of the default to cache the report for 10080 minutes. This would allow them to be ran on demand. Yes, I realize that Microsoft's intention is to lessen the load on the database, but the nature of the reports that I need to run require them to be ran on demand with the current data in the database and not a previously cached version of the report.
Thanks
We had the same problem and it turned out to be the report deployment tool we use (RSBuild) that was setting the cache for each report. We removed the caching from the deployment config file and redeployed the report and the problem went away.