Prior to update no issues. Over the last couple days, however, I keep getting hits with complaints that various sales orders won’t print.
System monitor shows them stuck in “Rendering Report”.
No Errors… so they don’t hit any system logs for me to see what and why they’re getting hung up.
No issues (that I can find) with OrderAck RDL/RDD.
The base, stock, ugly as hell standard SSRS WILL print. but not my custom versions. So, assuming there is an issue with my custom report styles… but all was well prior to the latest update.
Is anybody else seeing any SSRS issues?
Does anybody know of any changes the 2024.2 update made to… well, anything… that may impact this?
I can certainly tweak my RDL/RDD’s as required, but I’m not even sure where to start looking. All I know is they get stuck.
I’m having issues. I couldn’t get a certain BAQ Report to run after the upgrade, so I re-created it and it will not run. I keep seeing this error: Program Ice.Services.Lib.RunTask when executing task 4039776 raised an unexpected exception with the following message: RunTask: Ice.Core.SsrsReporting.SsrsCaller.SsrsException: The SSRS server returned the status code 500 (InternalServerError) with the following error text: The name of the item '' is not valid. The name must be less than 260 characters long. The name must not start with a slash character or contain a reserved character. Other restrictions apply. For more information on valid item names, see https://go.microsoft.com/fwlink/?LinkId=398858. ---> Microsoft.ReportingServices.Diagnostics.Utilities.InvalidItemNameException
Yeah, I’ve been scrutinizing every field on sales orders that WILL render vs ones that WON’T and for the life of me, I can’t find a pattern.
Feel like I should start over from scratch and rebuild… but then I keep reminding myself that this report has been in use for a couple years without issue… so something changed on the data, server, and/or service side to cause the issue. But no idea how I’m supposed to find it.
And if it isn’t reproducible… AND it only happens with my custom styles… EpC’s just going to slow play this issue (especially on top of all the other upgrade issues that are flying around).
They at least gave me a datafix yesterday so I could delete the stalled reports so I could keep trying. I kept getting the “Bitch, Be Patient!” message every time I tried to tweak something and print again, so troubleshooting at all was impossible until i was able to clear those stuck renders out of active tasks.
We are also having issues with two reports. I rebuilt the RDD and re-uploaded the last working version of the RDL. Everything went in fine but we are still receving an error. Currently waiting on a response from Epicare. Heres my error in case it helps…
Program Ice.Services.Lib.RunTask when executing task 842922 raised an unexpected exception with the following message: RunTask:
Ice.Core.SsrsReporting.SsrsCaller.SsrsException: The SSRS server returned the status code 500 (InternalServerError) with the following error text:
The operation you are attempting on item 'ScrapCustom' is not allowed for this item type. ---> Microsoft.ReportingServices.Diagnostics.Utilities.WrongItemTypeException: The operation you are attempting on item 'ScrapCustom' is not allowed for this item type.
at Ice.Core.SsrsReporting.SsrsCaller.SoapCaller.Call[TContent,TResponse,TSoapHeader](String actionName, TContent content, TSoapHeader soapHeader) in C:\_releases\ICE\ICE4.3.200.4\Source\Server\Internal\Lib\TaskLib\SsrsReporting\SsrsCaller\SoapCaller.cs:line 47
at Ice.Core.SsrsReporting.ReportProcessorBase.IsLatestVersionDeployed(IReportingService reportingService, String itemPath, String contentHashForLatestVersion) in C:\_releases\ICE\ICE4.3.200.4\Source\Server\Internal\Lib\TaskLib\SsrsReporting\ReportProcessorBase.cs:line 394
at Ice.Core.SsrsReporting.ReportProcessorBase.DeployReportIfNeeded(String printProgram, String fullReportPath, SsrsConfigurationInformation configurationInfo, Func`1 reportingServiceCreator) in C:\_releases\ICE\ICE4.3.200.4\Source\Server\Internal\Lib\TaskLib\SsrsReporting\ReportProcessorBase.cs:line 447
at Ice.Core.SsrsReporting.ReportProcessorBase.RenderReport_HttpClient(String ssrsRenderFormat, String printProgram, Boolean ignorePageSettings) in C:\_releases\ICE\ICE4.3.200.4\Source\Server\Internal\Lib\TaskLib\SsrsReporting\ReportProcessorBase.cs:line 373
at Ice.Core.SsrsReporting.ReportProcessorBase.RenderReport(String ssrsRenderFormat, String printProgram, Boolean ignorePageSettings) in C:\_releases\ICE\ICE4.3.200.4\Source\Server\Internal\Lib\TaskLib\SsrsReporting\ReportProcessorBase.cs:line 278
at Ice.Core.SsrsReporting.ReportProcessorBase.ProcessReportPart(String reportLocation) in C:\_releases\ICE\ICE4.3.200.4\Source\Server\Internal\Lib\TaskLib\SsrsReporting\ReportProcessorBase.cs:line 166
at Ice.Core.RoutingAndBreaking.ReportPersister.Persist(ReportInstanceInformation reportInstance, Func`2 reportsRenderer, Action`1 fillSysRptLstRow, Action`2 processReport, Func`3 filterTableAttachmentsFunc) in C:\_releases\ICE\ICE4.3.200.4\Source\Server\Internal\Lib\TaskLib\RoutingAndBreaking\ReportPersister.cs:line 58
at Ice.Core.RptBase.ReportSsrsDatabaseBuilder.RenderUnroutedSsrsReport() in C:\_releases\ICE\ICE4.3.200.4\Source\Server\Internal\Lib\TaskLib\RptBase\ReportSsrsDatabaseBuilder.cs:line 360
at Ice.Core.RptTaskBase`1.XMLClose() in C:\_releases\ICE\ICE4.3.200.4\Source\Server\Internal\Lib\TaskLib\RptBase\RptTaskBase.cs:line 224
at Ice.Hosting.TaskCaller.InnerExecuteTask(IceDataContext newContext) in C:\_releases\ICE\ICE4.3.200.0\Source\Server\Framework\Epicor.Ice\Hosting\TaskCaller\TaskCaller.cs:line 70
at Ice.Hosting.TaskCaller.ExecuteTask() in C:\_releases\ICE\ICE4.3.200.0\Source\Server\Framework\Epicor.Ice\Hosting\TaskCaller\TaskCaller.cs:line 61
at Ice.Lib.RunTask.BpmFriendlyTaskLauncher.Run(String sessionIdPrefix, IceContext db, Action taskRunner) in C:\_releases\ICE\ICE4.3.200.0\Source\Server\Services\Lib\RunTask\BpmFriendlyTaskLauncher.cs:line 57
at Ice.Services.Lib.RunTaskSvc.InnerRunTask(Int64 ipTaskNum, Boolean suppressTransaction) in C:\_releases\ICE\ICE4.3.200.0\Source\Server\Services\Lib\RunTask\RunTask.cs:line 471
I’m not sure if this is the same issue, but we were receiving a similar issue after our upgrade when the path to the custom report went down another folder past CustomReports.
ex. before the path was “reports/CustomReports/foo/bar”, but when simplified to “reports/CustomReports/bar” it worked fine. I think it looks for the .rdl immediately after CustomReports.
I also had to reupload a few reports that were made in classic report style maintenance from Kinetic using Kinetic’s .zip file upload.
Dealing with the same SSRS folder issue since the recent upgrade to 2024.2.5. We’re on cloud so some of the ‘legacy fixes’ (this issue seems to be recurring since 2017) don’t apply.
I’ll try the zip file route and report back.
No luck on the zip file route. I tried a few times with different folder structures.
Epicor has suggested I recreate the BAQ report using the RDD method (not BAQ Report Designer).
I will try this now and report back.
To close out my contribution to this post, I recreated the report using the RDD method. This works, but is a real pain. I have several BAQ reports that (I guess) can fail at any time requiring me to rebuild using RDD.
I did confirm with Epicor that the BAQ designer is still supported, so the issue does need to be addressed. We shall see.
I found that @LoganDing was correct. The main issue I had was they had changed around the report names. We are SaaS so this is more of a problem then it would normally be. I created a new report style, used the existing RDD, created a fresh SSRS report. Used my backup and copied over to the fresh one. Uploaded this and changed the report in menu maintenance. This resolved the issue for me. Hopefully if you were to use this method you could avoid re-creating the RDD. I know some of those are fairly intricate. Best of luck!
Things are getting a littler clearer now. My last post announced that I had recreated my report using RDD instead of BAQ Report Designer.
As I was re-creating the report I noticed, at the end of the Epicor KB, there is a note to leave to Report Location field empty. I made a mental note and decided to retry my original report for kicks and giggles. In all previous attempts, I had specified the report location, sometimes shortening the address by a folder level, as in @LoganDing 's earlier post - without success.
On this final attempt…
I created the original report (slightly different name) using BAQ Report designer.
Verified it auto-created the 1st Rpt Style (and report location - which I did not enter or alter)
I downloaded the report (RDL) in the Report Style Manager
Copied over the RDL that I had designed (the actual original report that had stopped working).
Uploaded the report (in Report Style Manager). This was successful!
Ran the report, popped a bottle of champagne, and realized this could have been so much easier with a little more clarity from Epicor.
So it seems to me that the report location must be auto-completed upon report creation/re-establishment. When copying a report style, you do have the opportunity to specify a new folder. I GUESS this is where the possibility of an issue is introduced.
Also unclear is when and why the report will fail post-update/upgrade, but at least we have a pretty good knowledge base here to work with.
Awesome, this is great to know as I didn’t do it that way either. I’ll have to keep that in mind when creating these to not change the locations. I guess that just makes me wonder how you are supposed to have multiple report styles without specifying the location. It will attempt to overwrite the existing if you leave the location blank(It also does it if you specify the location). Seems to still be a bit of a disconnect. Either way that is great information, thank you!
And thank YOU for helping with this team event!
One quick clarification about creating additional styles…
You get to specify a new description for your style, which is used as the name of the copied report. This is the differentiation you’re looking for (in additional to the Style Number).
The problem seems to be that we also have the ability to specify a folder IN ADDITION to the description. I use this capability all the time in order to organize my reports. I think we need to pay attention to this aspect.
Correction to this post: When copying a style, we MUST specify a new folder in the “copy style” dialog box in order to have Epicor create a new (additional) RDL. The name/description of the style is inconsequential. The Folder is used to separate distinct styles.
Absolutely! That’s interesting I just attempted that in pilot and it will only go based off the report ID. Which in this case is Custom Scrap, so in other words it is overwriting regardless of the description. Any ideas? I would think the only way around it would be to make a new Report/Report Style.
Don,
Think of report styles as variations of a single report. For example, you create a report that lists sales across months of the year (Style 1), but every quarter, you want to present that report summarized to the quarter. No sense creating a new report because you have all the data you need. For this, you copy style 1 and name it “Qtly Reports” in the Description.
This second style is based on the same report, but once you download it and open it in Report Builder, you create the subtotals and other grouping elements that you need in this “version” of the same report.
At the end, you have a single “report”, but now 2 versions that you can run as necessary - the source of the data is shared between the 2 styles.
If you need a new version that incorporates manufacturing of the items being sold, you then have to think, can I modify the existing “report”, to add all the job-related elements, so that I can create a third style, or do I have to create a whole new report which will include all this additional data for this NEW perspective.
In this case you’d likely create a new report and the first style would be based on all this new data you’ve created.
Sorry if this is rudimentary stuff you’re already familiar with, but it sounds like you may be confusing the purpose of the report with the purpose of the style.
Totally fine, I need a good picture drawn once in awhile. I guess my confusion at that point would be how would you have different data in the same RDL? Wouldn’t you need a new rdl no matter what?
I think I may have provided more info than necessary.
If your concern is what’s happening in the Report Location field, just make sure your description AND FOLDER are different and you will have a different style.
Also, don’t “create” new styles. You have to COPY an existing style and rename it to what you want - specify the folder name (as the style is copied) as you will NEED a separate folder for each different style.
