Share via

ReferenceTable & Table References on EDT

  • Article

 

This post attempts to explain the behaviors of the ReferenceTable property and Table References node on Extended Data Types in Microsoft Dynamics AX 2012

Synopsis: Lookup & View Details behavior are controlled by Relations (either Table Relations or legacy EDT Relations) for controls bound to table fields. Controls that are not bound to table fields, but have their ExtendedDataType property set, have their Lookup & View Details behavior controlled by the EDT settings ReferenceTable & Table References.

I recently saw a bug come through regarding the Table References functionality on EDTs not working correctly. Since I had no idea what the expected behavior was of this node (especially in relation to the ReferenceTable property) I started playing around with it some and contacted some developers on the appropriate team to find out what the expected behavior of these items was supposed to be. Below is a summary of what I have found out.

Notes:

  • Whenever creating an EDT which will set the ReferenceTable property, the core type of the EDT must match the type of the PrimaryKey on the ReferenceTable (i.e. Int64 for tables that use SurrogateKeys).
  • I will be using the terms bound and unbound controls in the following manner:
    • Bound control = a form control that is bound to a table field by having its DataSource & DataField (or ReferenceField) properties set.
    • Unbound control = a form control that is not bound to a table field, but has its ExtendedDataType property set. The most common use of unbound controls is in Dialogs.

 

Here we go…

 

If you only set an EDT’s ReferenceTable property here’s what you’ll get out of it:

Unbound controls that use this EDT will get Lookup and View Details behavior as long as the table you are pointing to uses SurrogateKey as its PrimaryKey. So if you point to DirPartyTable, you’ll get these behaviors, but if you point to CustTable (which doesn’t use a SurrogateKey) you won’t (without one more step that we’ll get to in the next section). 

Another behavior you will get by setting the ReferenceTable property is when you drag this EDT onto the Fields list of a Table, you will be prompted with this dialog:

image

If you hit Yes to this dialog, a new PrimaryKey based ForeignKey relation will be created automatically. Once you have this table relation, any controls that are bound to this table field will have Lookup and View Details up and running to the table that was specified in the ReferenceTable property. If you do not add this relation, bound controls will not get Lookup/View Details behavior (also, when you drag this table field onto a form design, you won’t get a ReferenceGroup, you’ll get an Int64Control).

If you alsoadd a Table Reference here’s what you’ll get out of it:

Actually there are a couple of different scenarios…

If you set the RelatedField property to the PrimaryKey field of the ReferenceTable, you will get exactly the same behavior as if you had only set the ReferenceTable property, with the exception that unbound controls will get Lookup/View Details behavior regardless of the type of PrimaryKey they are using. This discrepancy is probably a bug (which I will look into).

imageExample EDT for previous paragraph

If you set the RelatedField property to a field other than the PrimaryKey, you will get Lookup/View Details behavior for unbound controls, but you will not be prompted to add a ForeignKey relation when you drag this EDT onto the Fields list of a Table. If you don’t have a Relation defined using this table field you will not get Lookup/View Details for controls bound to this field. Note that for the unbound controls, the value returned from the lookup will be whatever field you set RelatedField to.

imageExample EDT for previous paragraph

If you also add a Filter here’s what you’ll get out of it:

Once you have added a Table Reference, you can additionally add Filters. Adding a filter to a Table Reference will restrict the rows that are displayed in the lookup. Take a look at the CaseProcess EDT for an example of this:

image

A lookup that uses this EDT (either an unbound control or a control bound to a table field that uses this EDT and has an appropriate relation) will restrict the records to those that satisfy the conditions that IsActive=1, IsTemplate=1 AND HierarchyType=5. Filters on different table fields are AND’d together where as Filters on the same field are OR’d together.

That’s all I got.

Synopsis redux: Lookup & View Details behavior are controlled by Relations (either Table Relations or legacy EDT Relations) for controls bound to table fields. Controls that are not bound to table fields, but have their ExtendedDataType property set, have their Lookup & View Details behavior controlled by the EDT settings ReferenceTable & Table References.

Comments

  • Anonymous
    June 26, 2013
    Hello, This post was really helpful ! Thank you. Have you finally figured out possible bugs ?

  • Anonymous
    July 10, 2014
    Fantastic post! Helped explain why sometimes I'd get prompted to add a FK and sometimes I wouldn't.

  • Anonymous
    May 27, 2015
    Dave, you covered various cases in a clean way. Thank you.