Appendix C. Source Code Changes Required for Upgrade

When you upgrade to Microsoft Dynamics AX 2009 from an earlier version, you must make changes to the source code to ensure that the internal references comply with the new best practices. These changes include code changes, metadata changes, and table modifications, as described in the following sections.

Code Changes

For fields of the int64 data type assigned to a 32-bit integer value, the assigned-to variable must be rewritten as a variable of the same type, or explicitly cast to an int value. For example,

int RecId = table.RecId;

must be rewritten like this:

RecId RecId = table.RecId;

When a variable that derives from int64 is used as an index to an array, the code must be refactored to use a map. For example,

int array[,1];
array[table.RecId] = 123;

must be written either as a map (in memory, used for few records), as shown here,

Map map = new Map(TypeId2Type(TypeId(RecId)),Types::Integer);
map.insert(table.RecId, 123);

or as a temporary table (on disk, used for many records), as shown here,

TmpTable tmp;
tmp.RecIdRef = table.RecId;
tmp.value    = 123;
tmp.insert();

For fields of the type int64 that are placed into a collection class, as shown here,

Set set = new Set(Types::integer);
Set.insert(myTable.RecId);

the code must be updated to use the appropriate data type, as shown here:

Set set = new Set (TypeId2Type(TypeId(RecId)));
Set.insert(myTable.RecId);

When a record ID is used inside a pack method, the code should be refactored to persist that record ID to a table field.

Metadata Changes

You should notice that the extended data type RefRecId derives from the RecId system data type and is automatically increased to 64 bit. The following are the extended data type requirements:

  • Extended data types used by fields that contain RecIds must derive from the RecId data type or one of its derived extended data types to automatically increase the extended data type to 64 bits.

  • Extended data types used by fields that contain RecIds must derive from the RefRecId extended data type or one of its derived types.

  • Extended data types must define a relation to the RecId column of a table if:

    • The extended data type has RefRecId as an ancestor type.

    • The extended data type has a deterministic relationship to exactly one other table.

  • Extended data types must not define a relation to the RecId column of a table if:

    • It doesn’t have RefRecId as an ancestor type.

    • The extended data type, or one of its derived types, can be used to refer to RecIds in more than one table.

  • Extended data types used by fields that contain table IDs must derive from the tableID data type.

  • Extended data types used by fields that contain table IDs should derive from the RefTableId extended data type.

Table Modifications

The following are the required table modifications for upgrade:

  • Table fields that contain a RecId (other than the system-defined RecId field itself) must be associated with an extended data type of RefRecId or one of its derived types.

    Note

    Note

    The RecId extended data type should be used only by the system RecId fields.

  • Table fields that contain a RecId (other than the system-defined RecId field) should be associated with an extended data type that is strictly derived from the RefRecId data type (not including the RefRecId data type itself).

  • Existing table fields that have RecId or RefRecId as an ancestor and define their own deterministic single-field relation should have that relation removed.

  • Relations must be defined for every table field associated with a RecId-derived extended data type (hereafter called RecId-derived field) that doesn’t define its own single fixed-field relations. Fixed-field relations (defined with the Related Field Fixed option when adding a relation on an extended data type) are those in which the related table depends on the value of another field.

  • If the table to which a RecId-derived field is related depends on the value of another field, and that other field contains an enumeration (or other value) to indicate the table to relate to for each row, one relation in the table must be defined for each value in the enumeration using a combination of a Related Field Fixed relation and a Normal relation.

  • If the table to which a RecId-derived field is related depends on the value of another field, and that other field contains table IDs, one of the following approaches must be adopted:

    • A relation must be defined for each legal value of the field containing the table ID. (From inspecting the Application Object Tree, you see that this is a very common approach.)

    • A single relation must be defined in the table to express that relationship in terms of the Common table.

  • All fields that are used to refer to a table ID must be associated with the RefTableId extended data type or a derived type.

    Note

    Note

    The tableID system type should be used only by the system-created tableID fields.

  • All fields that are used to refer to a table ID should be associated with a type strictly derived from RefTableId.

Multiple Time Zones

To support multiple time zones, a new type, UtcDateTime, has been introduced in Dynamics AX 2009.

Language Enhancements

A new primitive data type UtcDateTime is available in X++. This data type supports all operations that are supported by other existing primitive types, such as Int and Date. Here is an example of the new data type.

void CheckNewType()
{
    UtcDateTime utcDt;
    ;
    utcDt = 2000-03-14T22:10:10;
    print utcDt;
}

API Enhancements

New functions have been added that can be used when working with the new type. These functions have been added to the DateTimeUtil system class. All the functions in this class are static.

Metadata Enhancements

Metadata enhancements are provided at three levels. These changes allow you to create DateTime type nodes for extended data types, table fields, and form controls.

You can create extended data types of type DateTime as you do any other extended data type.

System Field Changes

The system fields have also changed. The CREATEDDATE and CREATEDTIME columns that store the date and time data separately have been merged to a single CREATEDDATETIME column. The existing CREATEDTIME column has been renamed to DEL_CREATEDTIME. Similarly, MODIFIEDDATE and MODIFIEDTIME have merged to MODIFIEDATETIME, and MODIFIEDTIME has been renamed to DEL_MODIFIEDTIME. A side-effect of this change is that the kernel-defined user types on which these columns are based have been renamed accordingly. The field IDs for these fields haven’t changed.

These columns always store the UTC date time value unless the application developer explicitly overrides it. For tables stored in the database, the UTC date time value is generated at the database. For tables using the native database, the UTC date time value is generated based on the machine’s clock setting.

The upgrade framework handles upgrades automatically. You don’t have to write upgrade scripts.

Upgraded System Fields

Existing tables that have the preceding system fields have been updated to the new system fields. When reading the metadata information from the AOD, we checked whether existing tables had either CreatedDate or CreatedTime. If either of those fields is set to Yes, the new CreatedDateTime property is set to Yes. Similarly, if an existing .xpo file for a table contains either CreatedDate or CreatedTime, the new property is set. When the table is saved or if it is exported, only the new property is saved.

Best Practice

Best Practice

Don’t explicitly overwrite system fields unless your application requires you to. And don’t overload system fields and use them for unrelated purposes in your application. It’s better to create a separate datetime field.

DateTime Control and Form Changes

You can use the new DateTime control in forms and map to DateTime database fields or any DateTime value.

Use the DisplayOption property to configure the control to show only date, only time, or both date and time values. The default auto option shows both the date and time values. Use the TimeZonePreference property to enable time zone conversions at the control level. For example, if you currently have an extended type configured to return UTC date time, you can instead convert to the user’s time zone by setting the TimeZonePreference property for the control.

Best Practice

Best Practice

The DateTime control should show the data in the user’s time zone.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset