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.
Hi @cchang
You asked about the server log. Cloud customers gain access via a program called “Server File Download,” located in System Management > Schedule Processes.
On-prem customers can presumably configure logs to appear in many places. My on-premises server (version 10.2.300.21) was installed using mostly default settings and places logs here:
C:\EpicorData\Companies\<company>\Log
Like some others who posted on this thread, I wasn’t able (or wasn’t smart enough) to determine the point of report breakage and took the approach of rewriting the reports, starting again with Epicor’s base RDD and base form.
Like Paul says, anything in the EpicorData folder is accessible from the Server File Download. Windows Event Logs are not, which IS a problem for SaaS users.
If you’re going to write to server’s file system, ALWAYS use the EpicorData folder. You can use this code in a BPM to find the path - which we never hardcode because you never know where it might be during a rebuild, moved to the cloud or whatever…
// ServerPath
//public struct PathInfo
//{
// public bool IsFile;
// public string FullName;
// public DateTime LastWriteTimeUtc;
// public long Length;
//}
//namespace Epicor.ServiceModel.Utilities
//{
// /// <summary>Pre-defined server folders</summary>
// public enum SpecialFolder
// {
// /// <summary>Reports folder</summary>
// Report,
// /// <summary>Web deployment folder</summary>
// WebDeployment,
// /// <summary>Report definition folder</summary>
// ReportDefinition,
// /// <summary>Custom report definition folder</summary>
// CustomReportDefinition,
// /// <summary>User data folder</summary>
// UserData,
// /// <summary>Company data folder</summary>
// CompanyData,
// /// <summary>Epicor Web Access virtual folder</summary>
// EWADeployment,
// /// <summary>Attachment folder</summary>
// Attachment,
// }
//}
var ServerPathSvc = Ice.Assemblies.ServiceRenderer.GetService<Ice.Contracts.ServerPathSvcContract>(this.Db);
// Get Folders
List<Ice.Lib.ServerPath.Types.PathInfo> PI;
using (ServerPathSvc)
{
// Get UserData folder
PI = ServerPathSvc.GetPaths(Epicor.ServiceModel.Utilities.SpecialFolder.UserData, "", false);
UserFolder = PI[0].FullName;
// Get CompanyData Folder
PI = ServerPathSvc.GetPaths(Epicor.ServiceModel.Utilities.SpecialFolder.CompanyData, "", false);
CompanyFolder = PI[0].FullName;
}
This is an old post but is still near the top of search results here: AR Form appears to have a bug related to externally-processed CSF system tables which I mention here: AR Form Error - #8 by josephmoeller
The KB article is not complete… I needed to delete 3 fields:
T4.Calc_MtExtPrice
T5.ProbReasonCode as Label_ProbReasonCode
T5.Calc_MtExtPrice as Label_Calc_MtExtPrice
