Try Microsoft Edge
A fast and secure browser that's designed for Windows 10
Hello,We are trying to upgrade our AX2012 Feature Pack to AX2012 R3.When we walk through the checklist for an in-place data upgrade , we noticed a problem with the derived tables.Before the synchronization we can see that EcoResProductInstanceValue is derived from EcoResInstanceValue.Because of this new way that AX implements this structure : in AOT you still have the 2 tables, but in SQL they have combined these tables in the parent table.Which means that in SQL in the EcoResInstanceValue table you now have all the fields that were originally in EcoResProductInstanceValue.Before synchronization :Here you can see the product id's are filled in .After the synchronization / flattening of the structure:Here you can see that after the flattening process, the product id's are not present and we lost the data.Any suggestions as to how we can resolve this issue ?
If that is the only issue I would create a job to copy the product field from the first table to the combined second based on recids. Or check the sync function and add the appropriate code to copy the field value for product.
Thank you for your answer,
however this is not the only place, CompanyInfo and DirPartyTable also show flattening issues.
These tables popped up while failing to create a unique index.
In this particular case I might be able to fix it like that but I don't have any guarantee that this will not have messed up any other data.
Like someone said I feel your pain. When we migrated from 2009 to 2012 R3 the conversion always failed. We ended up reloading data. DirPartyTable and the address book is a fun challenge. The unique index issue might be due to dirty data from a bug, a failed or incomplete entry showing up when the data was copied into the new more complex address relations.
Seriously one thing to check is that you have the latest conversion code. It was heavily patched during AX 2012 R3 *** releases.
Thank you for your response,
i have found the problem to this error
When you install the AOS, it creates certain stored procedures which are checked in the flattening script.
The reason the script isn't generated correctly is because the tables are already gone at that point.
The problem situated much earlier in the process, when the AOS is installed. When you install both AOS and DB at the same time, it will ask you to register for upgrade.
This was impossible since i came from FP and we needed the FP AOS for the split.
When the environment synchronized it removed these tables before the generation of the script and checking for this stored procedure.
The problem was i had customizations on certain tables which prevented me from running the checklist without syncing these tables , for example the presynchronize step .
It also did not show the synchronization progress dialog. So i knew he was syncing a lot more at that time. Actually this
So when i had this stored procedure , it was already too late ( the stored procedure is checked in the class SysDataUpgradeSCscTPT2TPH in the method isInUnFlattenMode()
I created the stored procedure myself after installing the AOS:
CREATE PROCEDURE [dbo].[TABLEPERTYPEINHERITANCEMODE] AS SELECT 1
The upgrade guide does not fully explain this issue. I will send some proposals concerning the guide to the support team.
Business Applications communities