I would think additional columns added to the database, and therefore the base ARForm RDD would be marked as “Excluded” by default.
If required columns were added during new development we would run into the same issue so we would exclude columns prior to release.
Maybe I’m not understanding how the upgrade causes the sql column limit.
I was thinking the issue was more with the RDL trying to use fields that were removed or renamed. And also trying to reapply custom fields to a significantly changed new report layout.
My problems have always been at the RDD level, can’t really speak to it more than that. It’s been a couple years since I’ve had to suffer through it but the fix was like you said going through the RDD and excluding unneeded columns and hoping for the best
Hi @Jonathan,
The mandate to switch to rewrite my AR Invoice from scratch came from Epicor Support; I presume you have access to support case CS0002011858 and can see the exchange there: “The custom ARForm will need to be rewritten for the new version, based on the new version’s Report Style and Report Data Definition.”
As for me, the error I received with the old form in System Monitor was a bunch of technical gibberish that surrounded the meat of the issue:
System.Exception: For more information about this error navigate to the report server on the local server machine, or enable remote errors
Until Epicor elects to make such errors accessible to its cloud customers, any claims of “cloud first” are only marketing fluff.
@PaulKile, rebuild from scratch with the new standard is their suggestion but doesn’t mean you can’t rescue your existing and tweak the RDD / RDL to uplift it up to 10.2.600 “new” standard. Watch the errors in System Monitor and tweak the RDD accordingly. Usually clues are in that “technical gibberish”
Yep, but non-cloud users too. Best security practices keep your devs off your production servers so the event log or a server log on the server is a terrible place to log.
Search for logging in the Enhancement sections. There’s been several proposed.
Ours broke as well. This is the third time during an upgrade from what I understand of the history, (I’m a newbie but trying to save this form after being told by Epicor to rebuild it from scratch-which we did and that did not work either!) Epicor has broken this vital form. 2016, 2018, and now 2020. We are working with our partner to convert the form with a BAQ as the basis and get away from the RDD completely. We knew it broke on 4/21, tried Epicor and they would not help since there is some customization, and spent literally the last several weeks trying to rebuild and recover. We still do not have a working invoice while we are building the BAQ.
Having lived in the ERP space for over 20 years (different products) I know these things sometimes happen, however, I am so disappointed in Epicor at the moment. Fixing and building these things does not come for free. Obviously this is not a new problem for users. I have scoured these posts and tried every suggestion and nothing worked to recover it.
We are on MT, looking to move to the public cloud in the future, however, that is another thing I find frustrating are the limitations on cloud customers.
Disclaimer-my personal opinions, not necessarily representative of my company.
In the end we didn’t have to rewrite the form completely. Although the same form was uploaded into both Production and Pilot the error message received was different, in Production the error was non specific
Query execution failed for dataset 'ARForm
but in Pilot the error was
Query execution failed for dataset ‘ARForm’. —> System.Data.SqlClient.SqlException: Invalid column name ‘Calc_MtExtPrice’. Invalid column name ‘ProbReasonCode’.
Removing those two fields from the query and re uploading it resulted in our form functioning again
I got the non-specific error Query execution failed for dataset ‘ARForm’.
Looked in the log files for the specific reporting server instance and it shows more details about which field was failing
From there, I navigate to the actual RDL associated with the Report Styles that consume it, in my case a custom RDL called ARFormJRF and open with report builder. Modified the dataset for ARForm.
Open the query phrase and removed the two references to a field “Calc_MtExtPrice”, saved, and re-ran the report with success.
It should be on the server where your reporting server lives and then just dig down to the appropriate instance of the reporting server and go to the log files.
I ran into more AR Invoice forms on 10.2.600.5, needed to remove another column from the report query (T5.ProbReasonCode) as it was causing issues. The report prints fine now, for me. But, other users are reporting that they cannot print at all in that environment. Crazy times…
Does anyone know what might be the issue with why a print preview on my machine will pop up a PDF but the same print preview on a different machine never does?
Does anyone know what might be the issue with why a print preview on my machine will pop up a PDF but the same print preview on a different machine never does?
For the other users, is it getting stuck in Scheduled Tasks or is it showing as complete but not actually popping up? If the latter, are they able to click print preview from the System Monitor to retrieve the report?
Yep the system monitor issue is definitely what it was. I deployed the client app with StartSystemMonitor set to false in the client config, when True is what I needed. Thanks!
Back to this fun thing. Although my “fixed” form is running fine, the server is logging an exception every time it runs. This error does not appear in the System Monitor at all.
Ice.Common.EpicorServerException: The number of report label columns for table RptLabels exceeds the maximum of 1024 and will be truncated. ---> System.Exception: The number of report label columns for table RptLabels exceeds the maximum of 1024 and will be truncated.
--- End of inner exception stack trace ---
So I’ve spent 4 days or so on trying to retrofit a NEW RDD (copy of the 10.2.600 ARForm and added my 3 tables and their relationships) to the existing AR Invoice RDL and that’s going horribly.
Of note, the base RDL ARForm does not use subreports for customer details anymore (which my customized version did because the stock RDL used to do that) and changes the header information pretty substantially to the point where I’m not really sure what else to do here.
Keep in mind this is a minorly customized form (Added a logo, a static text field, and a lot number field) that has been working for years and years and only minor upgrade changes needed for new versions. I am obviously venting a bit but this is honestly ridiculous.
So my option now is to, having re-build an RDD from scratch, re-customize a base version of their AR Form and try to get all the things to look and function the way it has for years.
Two thumbs down on this change, there’s gotta be a better way to do this.
Our friend @Aaron_Moreng pleads for a better way, and one exists if Epicor elects to use it: Public roadmaps & versioning. Epicor could easily publicize something like, “we intend to transform capability X starting in version Y and the old capability will continue to have legacy support until date Z.” For a period of a few releases, Epicor would then support two versions of the functionality, like ARForm and ARFormV2 (with associated RDDs), but still eventually drop the old version. For RDDs, behind the scenes Epicor could hide database schema changes using views, for example. This versioning strategy would support a speedy customer migration to new software versions, while allowing some changes to be made on the customer’s schedule (any time before date Z).
102.200.6 to 10.2.700.6
Had the same error message about those two fields. Had to get the log from the server, though. Did not appear in the system monitor details
Query execution failed for dataset ‘ARForm’. —> System.Data.SqlClient.SqlException: Invalid column name ‘Calc_MtExtPrice’. Invalid column name ‘ProbReasonCode’.
Once those two fields were removed from the AR Form query, the report rendered.
Ran into this same error, but I only removed the Report Table references for the fields (T5).
Also have a Custom RDD here, but when I reviewed the Standard SSRS report and it’s RDD both fields were included.
Removing the Report Labels references to these fields caused the Report to render ok.
It’s weird it work with the Standard RDD & SSRS though both are the same.
Might be related to the field count limititation.
