I have a problem with a report. I’ve added fields in the CustAgingReportTmp table (not temporary) and I want to add them in the CustAgingReport. It looks simple as I have done this several times.
My problem is that I don’t see these new fields in the dataset when I resfresh it or when I search the rdp in the list.
I’ve tried a lot of things with no results :
Delete *.AUC files and usage data.
Compile all the classes bounded to the report
Delete data in the SRSReportQuery table
Reset AOD and Dictionary cache
Full CIL-Compile
Synchronize the database
Restart the AOS and Reporting Services
Create a new report with this RDP
Nothing has changed. I can’t see them.
We works in AX 2012 R2 CU6 with Visual Studio 2010.
There was a config file used by VS for the dataset in the following folder pointing to a wrong AOS : C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\Microsoft.Dynamics.AX.ReportConfiguration.axc.
My solution If I want to add new fields or modify something to my previous ssrs report even if I refresh the Dataset and it still not effect or change I just restart the SQL Server Reporting Services (MSSQLSERVER) in services.msc but not the whole AX System only the Reporting services then Everything just take effect.
Even if you restarded the SQL Reporting Services then it does not change I think you need to create a new class then change the name of it not the as your previuos class RDP the use it or if that does not solve the problem One time Ive experienced it Ive created ne Temp Table I for my RDP not just like the previous then Compiled it all then the changes effects already.
Half of the development time is spent playing various strange tricks to refresh caches in AOS or in Reporting Services or just switching between AX and Visual Studio to check some label definitions or update data provider and report contract. Not to mention design limitations, strange difference between preview and final report, performance issues, overhead of configuration ending in error prone environments, etc.
That’s why we use a third party Docentric AX that solves all those well-known issues and decreases greatly our resource consumption: development capacities, hardware, cost, time and nerves :).