Key Benefits of Replacement and Surrogate Keys

Andrew Doughtery

The Microsoft Dynamics AX/D365 Support Team at Avantiico is focused on solving our client’s problems, from daily issues to large and more complex problems.

See All Posts

May 12th, 2015
10:14 AM
No Comments
Read Time: 1 Hour

Microsoft Dynamics® AX 2012 introduced the concept of surrogate keys and replacement keys to make life easier on the back-end database and the users responsible for creating forms. This blog post will define each of those terms as well as define the Auto Identification field group and reference groups. The goal of this blog post is to identify the key benefits of replacement and surrogate keys.

This blog post will also explain how to set up a form using reference groups to refer to a surrogate key field. Last, it will detail a common failure scenario when attempting to create a reference group.

What Is A Surrogate Key?

In AX 2012, a surrogate key is the auto-generated primary key for a table in the database. The surrogate key is linked to the already existing RecId field within any table. This means that the surrogate key is a unique 64-bit integer value that is mandatory for the table and cannot be changed or have duplicates. The fact that it is a 64-bit integer (int64) value means table operations normally perform faster than other types of field such as string fields. This is the main strength of surrogate keys.

What Is A Replacement Index?

While a surrogate key is great for lookup and database performance, it is not useful for the end user because it gives no indication of the table’s purpose, or what related tables it is linked to. For this reason AX 2012 has added the ‘Replacement Key’ index property for tables. The replacement key index is a dropdown of alternate keys that have been specified for the table. There can be any number of alternate keys for a table but only a single replacement key. More than one field can be specified under a replacement key, and it is these fields that will be displayed to the end user on a form instead of the surrogate key field.

What Is An Alternate Key?

A table can have any number of alternate keys. An alternate key may be a natural key or a single field primary key used in foreign or primary key relations with other tables. In either case, to set one, the user must create a new index and then set AllowDuplicates to “No” and AlternateKey to “Yes”. If AllowDuplicates is not set to “No” then AlternateKey should be greyed out and uneditable.

What Is Auto-Identification?

AutoIdentification is one of the system field groups for a table. If a replacement key is set this table will auto-populate with the field(s) specified in the replacement key index only if the ‘AutoPopulate’ property is set for the AutoIdentification field group. Otherwise, the fields can be dragged manually into the field group.

By default the reference group for a form will look to the AutoIdentification field to replace the surrogate key value for dragging and dropping from the datasource of the form. Users can set up their own field group and set the reference group to reference this field group instead of the auto-populated AutoIdentification field.

What Is A Reference Group?

In the form designer a reference group is a way of displaying the replacement key index fields for a table instead of the surrogate key, which is normally the RecId, for the table.

Upgrade or Migrate to Dynamics 365

Join the Avantiico team as they show you best practices for the Upgrade or Migrate to Dynamics 365' Roadmap.

New Event

Setting Up A Form

Now that the terms have been defined, let’s set up a form.

From this table and properties window, it is clear that the table’s primary key field is a surrogate key. That surrogate key above is the RecId field which is again, a unique, int64 value field, and is a mandatory system generated field. Below the ClusterIndex field is the ReplacementKey field, which in this case is an index called “LocationIdx”.

This index shows up as a selectable option in the dropdown because the index is set up as an alternate key.

Once the replacement key is selected the AutoIdentification field group should auto-populate with the field(s) specified in the “LocationIdx” index.

There is a user created field group here called ReferenceGroup. This is not to be confused with the reference group control type for forms. The field group was named this way to make it clear that the purpose of this field group is to be used for form reference groups. The idea here is that if the user wants to display other fields which are not part of the replacement key index they cannot use the AutoIdentification field group since it is auto-populated. This issue becomes more apparent when creating a single field alternate key.

The next step is to create a second table which will have a foreign key relation to the first table.

Here, a second table was created with a foreign key relation to the surrogate key field of the first table. Notice how the table stores an int64 field to refer to the LocationId field. This LocationId field is a created extended data type (EDT) that extends RefRecId, for this example. The purpose of creating this EDT is to more easily establish the foreign key relation when the EDT is dragged into the table from the AOT. The form will not display this long integer value if a reference group is properly set up.

Finally, create a form with the Second Table as a datasource. Drag the important fields into a grid control within the form. The resulting form should look similar to Figure 7.

Because a replacement key was set on the first table, which populated the AutoIdentificationfield group, and the second table is linked to the first table by a surrogate key, when the “LocationId” field is dragged into the designer from the form datasource – it will automatically create a ReferenceGroup control which converts the int64 surrogate key value into the easier to understand fields specified in the AutoIdentification field group. If the AutoIdentifcation field group is not populated, the drag and drop of the above surrogate key field will not be converted to a reference field group and instead will be added as the int64 field. All is not lost though as you can still create a reference group control manually and then set the field group you want to display – this can be any table field group, for example the ReferenceGroup field group that was created in the example. Therefore, it is not mandatory to have a ReplacementKey index and AutoIdentification field group set on the table, this is for convenience and allows the int64 surrogate key to be replaced with the ReferenceGroupfield group when the control is dragged to the form design from the form data source.

Highlighted in black in Figure 7 is what can happen if the user attempts to drag in the int64 field from the data source and the replacement key is not set up properly. In this example, the replacement key for the first table was blanked out which also blanked out the AutoIdentification field group. Therefore, the surrogate key was selected and not the contents of the AutoIdentification field group. The AutoIdentification group (which is derived from the replacement key index fields) needs to be selected for reference groups to work when dragging in a surrogate key field from a form datasource.

Accounts Receivable Account Training

Microsoft Dynamics® AX 2012 introduced the concept of surrogate keys and replacement keys which can lead to better performing databases, and benefits users who create forms by better clarifying table fields. This allows for a better user experience by avoiding an unclear, long numbers within a form record. From this blog, users gained a better understanding of surrogate keys, replacement keys, alternate keys, auto identification field groups, and reference groups. In addition, we set up two scenarios: (1) creating a form with a reference group that was set up correctly, and (2) creating a form with a reference group that was set up incorrectly. These two examples are beneficial to users as it compares.

While surrogate keys and replacement keys are helpful to users, they are not required for functional tables and forms. If you still want to learn more about table keys, check out this link from the Microsoft Developer Network.

Have any questions related to surrogate keys, reference groups on forms, and replacement keys, feel free to leave your question in the form below. An Avantiico team member will get back to you shortly.

If your organization have any training needs related to Microsoft Dynamics AX 4 SP1, AX 4 SP2, AX 4 RTM, AX2009, AX2009 RTM, AX2009 SP1, AX2012 RTM, AX2012 R2, AX2012 R3 or the new Microsoft Dynamics 365 for Finance & Operations reach out today and we will assist you. Avantiico’s AX Business Consultants work from local Avantiico offices in California (San Diego, Irvine, Temecula, Santa Monica) if they are not onsite.

You can also send Avantiico’s support and training team an email to info@avantiico.com or call Avantiico on (619) 483-4180 and our AX/D365 experts will find a solution that fits you the best.