Our support engineers have assembled the top recommended solutions for you.
Microsoft Dynamics AX 2012CRM Connector in Microsoft Dynamics AX 2012Financials Management in Microsoft Dynamics AX 2012Upgrading to Microsoft Dynamics AX 2012
Microsoft Dynamics AX 2009
Application Object Server (AOS)
Enterprise Portal and Role Centers
Inventory Costing in Microsoft Dynamics AX 2009
Invoice Settlements/Discounts/Reversals
SSRS and SSAS Integration
Workflow
Hi everybody.
I am trying to modify the InventValue SSRS report in AX 2012, but have run into some problems.
I have added three new fields to the table "InventValueReportTmpLine" which is used in the report's dataset.
I have also modified the "InventValueReportPopulateItem" and "InventValueReportDP" classes in order to populate the new fields.
Data for the new fields are generated without errors.
When executing the Report in a browser, the report correctly shows data from the new fields - but when executing the report in an AX client, the fields are empty.
In the report layout the new fields are set to always visible.
I have tried to delete all caches and also done a full CIL-compile without problems.
Can anyone help me with this small problem?
With regards
bhlj
Bo Jensen
Hi again
I forgot to mention the following modifications in my initial post:
I have also modified the AOT query "InventValueReportTmpLine" to include the new fields.
I have also added the new fields in table "InventValueReportTmpLine" to the fieldgroups "AllFields" and "AutoReport"
Hi Bo,
you can try these in general for all the report customization
Make the table regular and execute the report. Make the table visible and check data in it. IF you have data properly fetched in your "InventValueReportTmpLine" ie report TMP table then it could be a cache issue else your logic in filling the fields might have gone for toss.
Removing cache for report involves,
1)deleting the report from report server.
2)deleting data from SRSReportQuery table along with SysLastValues
3)since you have chnaged the report's data set table you need to compile forward the Dp class
4) Refresh the data source,
5) Add the fields in design
6)Save the report back to Aot
7)close ax restart AOS and SSRS service (Generally restart SSRS service will suffice )
8) open Ax and deploy the report
these steps are required because the report executes on BI services and internally uses metadataservice to get the dataset required for the report. This is always cached and any changes made to the TMP table returned by the Ax dp class will always cause the following error if its already executed atleast onece
MetaData exception object instace not ---------
I just explained what was going on for this issue. It's been around forever and is a very common problem when you update fields in the AOT. This isn't a cache issue. My explanation is provided here. This is something that gets everyone when they first start.
community.dynamics.com/.../97859.aspx
This is very, very common. Remember, if the AOT dataset is not updated, empty fields will display. Recreating a report works because you force an updated version of the AOT but you don't have to do that. There are just missing steps here.
This sort of behavior is not frequent if you use a SQL datasource by the way. Read this comment from Microsoft on the problem warnig you about updating queries in the AOT:
http://msdn.microsoft.com/en-us/library/cc621410(v=ax.50).aspx
If your report uses the predefined Dynamics AX data source and a query that is defined in the AOT in Microsoft Dynamics AX, you must be especially careful when updating the query in the AOT. For example, if you remove a field in the query and the field displays in the report, the report will display an empty column for the field. Whenever you make updates to a query, be sure to consider how those updates may affect your reports. Updates to a query may also require updates to your reports.
Here would be the updated steps for 2012:
technet.microsoft.com/.../cc569485.aspx
And make sure that you've unchecked, the "use static design" checkbox when you redeploy your report. That stops the static RDL from being generated. That often fixes a lot of stuff (do a google on any number of blogs). I've also seen cases where people fixed it by creating the updated AOT query as a new dataset, and setting the dataregion to use the new dataset (while deleting the old one). Finally, they performed a redeploy after that. And of course, just recreating the report always works. Redeploy will usually get you there for this error.
Independent, Freelance Consultant and Dynamics Development Instructor
http://www.instructorbrandon.com
http://www.youtube.com/user/BrandonAhmad
Hi Brandon and thanks for your response.. i will try to follow your instructions, but the first link you provided doesnt work.. when i click it, it opens this address which doesnt work in my browser
http:///product/ax/f/33/t/97859.aspx??WLXID=645bd08c-e95c-45dc-bbcf-68f1634e2c0e&RID=008668d5c78&TID=1357592300628&lid=
Hi venkatesh and thanks for your reply
But as I wrote in my initial posts, i can actually get data in the new fields, as long as I execute the report in an internet browser - the problem only occurs when executing from an AX client.
But I will try to follow both yours and Brandon's suggestions and reply when its done
You know, this is just one of those irritating problems. Everyone knows that the only thing that always works is recreating the report. After that, there are probabilities. I've found that just recreating the dataset and mapping it back to the report usually works, with a good deploy occuring next.
But there have been times where it failed. I think this is why Mirosoft held off on giving any guidance on how to fix it other than recommending a redeploy (which is what I linked to). They warned of the behavior as it is very common, and basically left a message saying to be careful with altering queries in the AOT then described what would happen. The behavior you described and several other posts here lately have described alluded to the exact same issue.
If you keep watching the forums, you'll see weekly posts on this issue.
What's good is that it isn't one of those errors that will stop production or anything. You can always recreate the report if worse comes to worse. But what is irritating is having to worry about this every time that you want to update an AOT query.. sucks, but at least I don't sweat over the error anymore since I know that it is part of the product.
***reposting the first link: community.dynamics.com/.../97859.aspx***
Hi Brandon
Data for this particular report comes from two datasets which references "InventValueReportTmpLine" and "InventValueReportTmpLedgerLine" tables.
They have the "DynamicsAX" datasource and these queries respectively:
"SELECT * FROM InventValueReportDP.InventValueReportTmpLine"SELECT * FROM InventValueReportDP.InventValueReportTmpLedgerLine
The two InventValueReportTmp... tables are populated in the "InventValueReportPopulateItem" class and then displayed via the "InventValueReportDP" class.
I have tried the following without results (not in that order):
- restarting the Reporting Server
- Deleting and redeploying the report from both AX AOT and Visual Studio
- Delete *.AUC files for the AX client
- Reset AOD/Dictionaty/Data cache in AX
- Full CIL-Compile
- Compile forward of the "InventValueReportDP" class
How can I force an update for the "DynamicsAX" datasource in AOT and/or Reporting Server
Hi Brandon,
Adding new fields to query ,ReportTmp table always end me up with the meta data exceptions
Even during the pre-release of Ax 2012 we always followed the refresh the data set, add the fields in design.
save the report back to aod
close client reopen it. delete the report from report manager. restart ssrs service and then deploy the current version.
delete data from SRSReportQuery (this is required because the dynamics query used by report dialog with sysqueryform gets initialized from here if there is a record for the pirticular report in the cuurent user)
then we were able to save newer version of Report to version control be it VSTS or Source depo in pre-release.
Even if this fails we would restart AOS service (mostly not required)
regards
Venkatesh vadlamani