TABLE KEYS 2012

Ax2012 Table Keys.

We are going to see the concept of keys on Tables in Ax2012.

These all following keys that we are going though appears in the AOT Table properties window.

Primary Key

The primary key is usually the type of key that other tables, called child tables, refer to when a foreign key field in those other tables need a relational identifier.

When we create a new table in AX2012 the Primary key was enforced by an index that has one field, this field should be unique, by default the primary key is based on Recid field. This is represented as surrogateKey in the table properties primary index.

By default the CreateRecIdIndex property was true and ClusterIndex as surrogateKey.

The ClusterIndex value is given to the underlying Microsoft SQL Server database system as a performance tuning choice. This choice generally controls the physical sequence in which the records are stored in the underlying database.

ReplacementKey

This key is used to define the replacement fields to display in your design when you referred  to some relation using the Recid.

for ex:-

Table B is referring to Table A where the TableB have the Refrecid from Table A, but when you open the form for TableB We cant show the Recid of the TableA in the Presentation,So whatever the field that you want to display, you will define one index on TableA with the fields that you want to show and and index alternateKey property to Yes. define the Replacement key property for the table A as this index.

If a ReplacementKey is chosen, its fields can appear on forms to helpfully identify each record.The ReplacementKey should be a set of fields that represent the natural key.

In AX2012 Relation represents a foreign key.

In Ax2012 we will use different Terms that used to describe the keys, These terms we wont see anywhere in AX physically in property names.

Foriegn Key-In Microsoft Dynamics AX, an AOT node under MyTable > Relations represents a foreign key. 

natural key-A key whose value has meaning to people. Most replacement keys are natural keys.(ReplacementKey).

unique key-this applies to primary keys and to alternate keys. It does not apply to foreign keys. This term emphasizes that all values for a given key must be unique within one table. All fields in a unique key must be not-nullable.

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.

AUTOIDENTIFICATION

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 theAutoIdentification field group. Otherwise, the fields can be dragged manually into the field group.

Figure 1 – AutoPopulate for AutoIdentification field group set to ‘No’

Figure 2 – Because AutoPopulate is set to ‘No’, the ReplacementKey index field does not show up in AutoIdentification unless it is dragged in manually

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.

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.

SETTING UP A FORM

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

Figure 3 – SurrogateKey as PrimaryIndex for first table

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”.

Figure 4 – Setting up an AlternateKey which is a ReplacementKey

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.

Figure 5 – AutoIdentification example with replacement key auto-populated field

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.

Figure 6 – This is the Second Table with Foreign Key relation to First Table’s SurrogateKey

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.

Figure 7 – ReferenceGroup created on form.

Because a replacement key was set on the first table, which populated the AutoIdentification field 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 ReferenceGroup field group when the control is dragged to the form design from the form data source.

Figure 8 – Manually create a Reference Group

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.

Figure 9 – Proper Setup for Reference Group to Work

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? Leave your question in the form below and an AXMentor team member will get back to you shortly