Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2022 Release Wave 2Check out the latest updates and new features of Dynamics 365 released from October 2022 through March 2023
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
I am busy running through the Preprocessing upgrade check to upgrade an AX 4.0 system to Ax 2012. I am trying to solve all the upgrade readiness issues.
The one error I received is: readiness : Detect shared tables.
Error: Some source tables are shared table, preprocessing script should be modified to follow the correct pattern.Resolution: Look at preprocessing scripts for CustTable table within the ReleaseUpdateTransformDB40_Basic class.Details:Script ReleaseUpdateTransformDB40_Basic.validatesmmBusRelTableRecordsWithoutName has a shared source table SMMBUSRELTABLE.Script ReleaseUpdateTransformDB40_Basic.validateBusRelCustAccount has a shared source table SMMBUSRELTABLE.Script ReleaseUpdateTransformDB40_Basic.validateBusRelVendAccount has a shared source table SMMBUSRELTABLE.Script ReleaseUpdateTransformDB40_Basic.validateBusRelCustAndVendAccount has a shared source table SMMBUSRELTABLE.Script ReleaseUpdateTransformDB40_Basic.validateContactPersonRecordsWithoutName has a shared source table CONTACTPERSON.Script ReleaseUpdateTransformDB40_Basic.validateAddressStateReferenceData has a shared source table ADDRESSSTATE.Script ReleaseUpdateTransformDB40_Basic.validateAddressCountyReferenceData has a shared source table ADDRESSCOUNTY.Script ReleaseUpdateTransformDB40_Basic.validateAddressZipCode has a shared source table ADDRESSZIPCODE.Script ReleaseUpdateTransformDB40_Basic.validateAddressZipCodeReferenceData has a shared source table ADDRESSZIPCODE.
I am not sure what to do with this. The resolution says to look at the class and to modify it to follow the correct pattern, but I am not sure what the pattern should be and what to look for.
Does anyone have any ideas?
(I have already added the shared tables to the Table collections, and reran the update readiness script, but I am still getting this error.)
I am not technical to help on the actual error but I wanted to warn you that it's not recommended to use shared tables for customers in AX 2012 using the virtual tables and table collection. Microsoft will eventually share the cust and vend tables using the new 2012 architecture and they don't recommend to keep virtual tables as they might stop maintaining this feature.
If it's mandatory for you to share customers then you might want to think about writing your own code to automatically create or update the customer in all your entities.
in AX 2012 Table sharing is not recommended to share using Table collections,
Table collection is used to share tables using Virtual Company...
Consider setting the property -SaveDataPerCompany of table - 'NO'
Please verify and update us with your finding
Thanks for your answer. I just read this post on the SaveDataPerCompany property:
Apparently it's never a good idea to change the setting. It's quite a big change as it removes the DataAreaId field from the table. Since quite a lot of functions and reports use DataAreaId, removing the field from the table can cause loads of things to go wrong.
Because the tables mentioned are all address related tables, you should be able to ignore these errors because the AX upgrade scripts are already written to transform the address data into the new shared table structure that addresses in Dynamics AX 2012 use. Internally we have a list of common shared tables that can be ignored, and unfortunately we haven't updated that script to include the address tables that you mentioned. There isn't a way to keep them from showing up in the validation results, but you can safely ignore those validation errors.
You are correct that you do not want to change the tables in any way to SavePerCompany=No as that creates completely different behavior.
Business Applications communities