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.