Hello all.
I recently discovered that one of our local SSRS reports is having this problem for scheduled runs. In GOOESOFT_REQUEST, scheduled runs (type = 's') always have result_code = 's' and result_text = 'Error creating report snapshot'. The Maintain Schedules shows that the Next Run Date is incremented, but Last Run Date says "Never Run". The report runs fine when done manually.
So it seems like an issue with the snapshot folder, but I checked our settings in T_DEFAULTS and they're good. In fact, this is the only report that consistently has this problem. And it happens for anyone who schedules it (including myself, an admin), even people who have other scheduled reports that don't have problems.
My next step is to trouble-shoot the SSRS report itself, but I'm not sure where to start. Has anyone seen this behavior? Any suggestions?
Thanks very much!
Nathan
Hi Nathan!
I've sometimes noticed that SSRS reports that have trouble being scheduled (and spitting out the error you mention) usually have some sort of tiny flaw that doesn't appear when you run the report immediately via Tessitura. However, sometimes you'll see an "error" when you run the report in the Visual Studio designer in Preview. The error list might be some minor warnings (like "Transparent" isn't a real color, or something like that) - but I've often noticed when I remove those errors that appear in Preview, that I am suddenly able to successfully schedule the report. YRMV. :)
Beth
That's interesting, I'll start with that. Thanks very much!
Same here. Once it errors the tessitura environment needs to get restarted overnight. Just RS,SQL server or report server, or the windows servers they sit on alone isn't enough.
We can't run a basic SSRs report once the error occurs once.
Transparent issue is interesting.
Curious to see what other people find too.
We have been having loads of problems with our SSRS reports and scheduling, we quite often get the snapshot error or an error saying that the report server can't find the file.
First check the logs of the Web Reports service as this gives really good information about why the report failed. Often it can be a problem with a parameter if you have updated the underlying report.
Though sometime we even get issues with reports that usually work fine.
We have also found that if you reschedule the report from the database table, the report will run fine! You can reschedule a report by updating gooesoft_schedule_queue. When a report throws an error it will change the status of the request to "e". So to reschedule a report we just change the "e" to "s" and then the report is rescheduled.
Next time the report is run it picks up the snapshot and is sent through fine! Not sure why but it works for us. It has reduced the number of report producing errors no end!
We have setup a scheduled job to run every hour which runs the following script.
update gooesoft_schedule_queueset status = 's'where status = 'e'and computed_date > '01 Aug 2013'
I was seeing the folowing
ErrorError creating report snapshot: Service URI: https://<rest api serevr>/WebReports/Snapshot/Create/379863?auth=K%2fV6R1a1dgHBqh57QyrYZZgVuOy5YYzJzDnsiuPnvkdUW6W18yM%2fZsT7YBDW4Jtz Verb: POST StatusCode: 400 StatusDescription: Service Response: ErrorMessages: The operation has timed out XML Request: (None)
I ended up running Application Error Log every 30 minutes to try to get more of a grip on what the error was but that also seemed to solve the issue, so am not sure whether by doing this I was keeping the Web Reports, and therefore also SSRS and Rest Services, "warm" enough that they prevented that time out.
That has stopped the error being obvious now
Mark
Thanks for all the feedback. It looks like Beth's suggestion worked - I found that I was getting a "warning" in BIDS when running the report, but it didn't stop the report from rendering. I resolved that issue, and the schedules started working after that. It's an interesting insight, and I might have to re-visit some of my other reports as I probably have "warnings" like that in several of them (possibly ones that haven't been scheduled yet).
Hello again.
After a week or two of the report running, we started getting the snapshot error again. I tried out Nick's suggestion with the code to reschedule the report from within SQL, but had no luck. Then I took the spirit of Mark's approach and went low-tech: I scheduled a shorter report to run an hour or so earlier than the problem report, to "warm up" the services, and it looks like it's working.
Going to have to keep an eye on it, and I'll update this post if it starts to fail again - so I can bug you all for more suggestions!
Thanks once again for the help!
Update: I've been running a "warm-up" report on a schedule to try to get the services running so the user's report would complete, but was still getting the error until this week (the user's report fires off once a week). I scheduled my warm-up to run just 5 minutes before the user's, and it seems to be doing the trick now. I had scheduled mine an hour prior and was getting the snapshot error on the user's run, so it looks like the services are going to sleep at some point in that hour (or maybe we have processes running in that time that slow it down enough to cause the error).
Anyway, it seems to be working - at least for the time being. Hope this helps anyone else having a similar issue.
I was having these problems after upgrading to V12
after some troubleshooting, I established that shutting down the Report Server does not actually stop the process (i.e. it remains resident in memory).
So to remove report Server from memory:
1. Exit out of Report Server program.
2. Press CTRL+SHIFT+ESC to access Task Manager.
3. Look for gsrbatch.exe (this is the executable file for Report Server)
Should find that in left-most column ('Image Name' in Windows7 - )
4. Right-click on this and select end process. Select 'Yes'/End Process' to confirm.
5. Restart Report Server
Hope this helps with some of your problems.
David