Using an extension table for additional fields

There is a new pattern for adding fields to standard tables that has been used from AX 2012 R2, wherein fields are actually added to an extension table. This would be joined to the primary table in a 1:1 join. This seems like a silver bullet—we can add fields to a standard table without modifying it!

There are two main limitations with this, from the footprint perspective.

  • To maintain referential integrity, a delete action (or add an event handler to the delete method) must be placed on the parent table, otherwise, we will have orphaned records if the parent is deleted.
  • We have to modify the forms to handle the extension table.

Of course, we still have to modify the forms to show the fields. However, this is the same for both the methods. Therefore, to add a single field to a standard table involves more work, but with advantages, for example, all of the table and field event handling for the new fields are completely separate from the standard table.

There is a performance benefit on updates when only the standard or extension table needs to be updated, although this is mitigated by having to first seek the parent table to get the extension table record. It also avoids potential buffer size issues when adding a large number of fields, such as note fields.

There is nothing new here that we haven't done before, so we will just list the steps required. We will take an example of CustTable; the steps involved in implementing this pattern are as follows:

  1. Create the table named ConCustTableExt and add a primary key relation to CustTable, which will create a field named CustTable on our new table.

    Note

    This may seem odd to have the relation on the foreign table, but this helps reduce footprint and helps with referential integrity.

  2. Add fields as required to the new table using fields groups to simplify adding them to the relevant forms.
  3. Create a class to handle the delete event on CustTable; name it ConCustTableExtHandler.
  4. Create a method deleteEventHandler that will locate and delete the extension record.
  5. Add a subscription to the new event on CustTable's delete method.
  6. Add the new data source to the form CustTable and set the JoinSource property to CustTable.
  7. The relations are create in reverse for extension tables, so we have to modify the method, write for the data source CustTable, and add the following code after the call to super():
        if (!ConCustTableExt.RecId)
    {
        ConCustTableExt.CustTable = custTable.RecId;
        ConCustTableExt.write();
    }

You can then proceed to add fields as required to the form. In terms of deployment, you will have to handle the situation where there are customers without the extension table. This can be done by adding code to the form or writing a data initialization routine.

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

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