Weren’t you having success with solution workbench though? But when I think about it, how would you modify an RDL and get it in a solution if you can’t modify it to begin with as they are saying above.
Last time a few months ago on 2025.1 cloud I am sure I did it… haven’t touched them since though…
Does this seem to be increasing in frequency for anyone else? I’ve had a dozen reports fail to print today alone.
Update to my post above: over 50 failures with the same error:
An error occurred within the report server database. This may be due to a connection failure, timeout or low disk condition within the database.
We’re looking at >25% failure rate on SSRS… I’m not sure how we can continue to function if this continues.
Our errors were mostly caused by overlapping report style/rdd tasks firing simultaneously across different companies.
I created a SysTasks dashboard to help diagnose the issue, (it’s posted here) - one of the commonalities I found is that a report that errors is generally running at the same instant as a report that succeeded, of the same ReportID/StyleNum (maybe across companies, maybe not)
It looked to be a thread safety issue / resourcing issue that is relatively rare to run into as the SSRS server needs to be under heavy load, which is influenced by other customers as well.
They’ve not updated our case since 10-31, at which point I noticed that our errors stopped.
SSRS is a client/server architecture on cloud, I can’t help but wonder if they shuffled around who’s on what server since ours magically vanished and yours got worse!
You may refer them to CS0005076035 which has this error documented since 2025-08-25, and PRB0304935 which they marked as completed on 2025-09-19, (it was never actually fixed)
It took me a month to get them to re-open the PRB which is now in “Submitted to Development” status.
We’ve escalated this issue as high as we can go, good luck and god speed sir!
I’ve been copy/pasting every error as it shows up into my case. It’s big enough that it causes browser rendering issues and balloons memory usage in that tab…
The particular error you’re seeing is exacerbated by running a particularly heavy SSRS/RDD (something with a heavy SQL portion) running parallel with background processes such as “Multi-Company Direct Server Process” and “Automated Fulfillment Process”. I’ve encountered a smattering of errors at this point, but this one and another error regarding memory usage seemed to directly indicate to me that the SSRS server is under-resourced.
Also, at one point during the diagnostics, Epicor increased resource allocation to our SSRS server which definitely reduced the number of issues. This is documented in our case and you might want to ask if they can do that.
Additionally, there was at least two hotfixes deployed to SSRS architecture/production relating to this issue, which should hopefully be referenceable by Epicor on our case… (but it wouldn’t be the first time they didnt document what they did on a hotfix, the same problem happened to us later, and we had to walk through the whole diagnosis again…)
One hotfix was to increase logging verbosity on the SSRS ↔ App Server architecture as Epicor had nfi what was going on.
A few months later, and the other hotfix made changes they didn’t disclose to us, which was deployed last Monday.
Thanks for the info Gabe
This morning we got one error, which is the first we’ve seen since the hotfix last Monday.
So for us I guess the status would be “mitigated”? But not fixed. I updated our case with the “new” info.
Program Ice.Services.Lib.RunTask when executing task 6297102 raised an unexpected exception with the following message: RunTask:
Ice.Core.SsrsReporting.SsrsCaller.SsrsException: An error occurred within the report server database. This may be due to a connection failure, timeout or low disk condition within the database.
We have joined the Cloud SSRS reports failing club
I suspect we have been getting these for a while but yesterdays volume of errors brought it to light. Prior our users were just resubmitting their reports and it would run successful so they didn’t bother to report it to me. I have case CS0005182540 open with Epicor Support but based on what I am reading on this post and in PRB0304935…not expecting a quick fix
Our users frequently run the same reports with different parameters throughout a work day…this is nothing new and something Epicor should be able to handle.
FYI…response I received from Epicor Support on Case CS0005182540:
The hotfix that was implemented late September and early October addressed some of the causes of the Low Disk and other related errors, but not all.
The development team continues to collaborate closely with Microsoft to investigate and resolve the issue. The root cause has been identified as related to concurrency at scale, which has proven more complex than initially anticipated. Despite the challenges, the team remains committed and is actively working on the issue daily.
We have essentially a copy/paste of this update, and failures continue.