mfp: Uptaking installation specific IDs

[Blog bot]

Источник: http://blogs.msdn.com/b/mfp/archive/...cific-ids.aspx
==============
In Microsoft Dynamics AX 2012 we have solved the element id problem. The solution is outlined in this post. The solution consists of major changes both having an impact on existing AX 2009 and AX 4 solutions:

1. Element IDs (like class ID and table ID) are now 32 bit.
2. Element IDs are installation specific. The same class will have different IDs on different installations.

When making IDs 32 bit we had to deprecate the TypeId() function. TypeId() took one argument the name of an Base Enum or Extended Data Type. And it returned an integer value, where the upper 16 bits were the ID, and the lower 16 bits denoted if the type was a Base Enum or an Extended Data Type. For example: TypeId(MyEDT) returned 0xC351 000B = (50001 > 16 extendedTypeNum(MyEdt) typeId(myEnum) >> 16 enumNum(MyEnum) typeId2ExtendedTypeId(typeId(myEdt)) extendedTypeNum(MyEdt) As element IDs now are installation specific then we need to provide enough information for data export/import to convert the data correctly between the source and target system. There are 3 things to do:

1. Do not store IDs in containers,
   If IDs are stored in a non-relational format (like a container), then data export/import cannot identify them, and the IDs will be imported as-is; which means they will resolve incorrectly on the target system. A best practice rule is available to identify IDs in containers.
2. Use the right Extended Data Types on your fields (TableId, FieldId, ClassId, etc.)
   Data export will convert data using these Extended Data Types into a format that can be correctly resolved on the target system.
3. For fields containing field IDs

1. Set the RelatedTable property, OR
2. Create a new field group with the field referencing the table and the field referencing the field.

For data export/import to be able to correctly convert a field ID, it is required that you specify which table the field belongs to. If the field always belongs to the same table, you can use the RelatedTable property to specify it (3.1), OR if the field ID is referencing a field in an arbitrary table, you need to link the table reference and the field reference to each other. You do this by creating a new field group containing the two fields (3.2) THIS POST IS PROVIDED AS-IS AND CONFERS NO RIGHTS.




==============
Источник: http://blogs.msdn.com/b/mfp/archive/...cific-ids.aspx