Table Methods

Applies To: Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

Every table object has instance methods that can be categorized as either system-defined or application-defined.

System-defined Methods

Tables in Microsoft Dynamics AX have a number of system-defined methods, such as insert, validateField, validateWrite. For a list of these methods, see the xRecord system class. The xRecord class can be seen as the base class for the Common table. The Common table can be seen as the base table for all tables.

In any table class, the body of each system-defined method contains only a call to super(). When you edit the X++ code in a table method, you override the parent's implementation of that method. Usually the call to super() must remain in the methods that you edit.

The following table lists the methods that can be overridden. For rules and hints about overriding these classes, see Best Practices for Table Methods.

System-defined method



Executed when a delete operation is performed on a table object, before the operation is committed to the underlying database table.


Executed when an insert operation is performed on a table object, before the operation is committed to the underlying database table.

Insert is sometimes called create.


Executed when a read operation is performed on a table object.


Executed when an update operation is performed on a table object, before the operation is committed to the underlying database table.


Executed when a heading for a form is displayed.

super() in the caption method generates the text to be displayed from properties on the table.


Deletes the data and the state information for a table object.

When the clear method has been executed the records in the table hold NULL values.

When a query is executed on a table, the table object holds state information about the query including: selected columns, aggregates, joins, order by, table hints, and filters. A call to the clear method will delete all this data.


If the clear method is called in a loop (for example, a while select) that iterates through table fields, the loop will stop working as all the table object state information will be deleted.


Executed when a record is deleted.


Executed when you compare tables.


Executed when a help text for a field is displayed in the status bar, for example when you jump to the next field on a form.


Executed when a new record is added.

initValue is automatically called from forms.


Executed when a new record is inserted into the table.

If the record cannot be inserted, the super() call throws an exception.


Executed when two records are merged.


Executed when a field is modified in a form or Web form. Use this instead of placing code on the Form Control/Form data source field.


Executed when a record has been loaded.


Executed when the table's primary key is renamed.


Executed when a record is re-read.


Executed when the mouse pointer is placed on a field in a form.


Executed when a tooltip for the current field is to be displayed.

super() in toolTipRecord calls caption.


Executed when an existing record is modified.


Executed when a record is deleted.

validateDelete is automatically called from forms and is used to check whether the current record can be deleted.

The super() call checks whether there are related records in tables with delete actions of type Restricted. If there are such related records, super() in validateDelete will return false.

For more information, see Maintaining Data Integrity.


Executed when you leave a field in a record.

For example, after entering changes to a field on a grid control, you could click another field in that same record or on a different record. Or you could click another control on that same form.

The super() method invokes field validation checks, as guided by the value of the Validate property.


Executed when a record is written to the database, before the data change is committed in the database.

The super() call examines all fields for the setting of the Mandatory property.


Persists a record to the table.


Returns a string of XML that names all the fields defined in the table.

Application-defined Methods

You should create the following methods on any table with a unique key. By default they run on both the client and server. You can state this explicitly in the method declaration ("client server"), but you cannot specify a single tier ("client" or "server").

Application-defined method


static find

The parameters for find are the table's key, and an optional Boolean used to indicate select forUpdate.

Returns a record indicated by the key.

static exist

The parameter for exist is the table's key.

Returns true if a record with the supplied key exists.

If a select statement is used to obtain the key value for the input parameter, the select should return exactly one record with exactly one field.

static checkExist

The parameter for checkExist is the table's key.

Returns true if a record with the supplied key exists. The prefix 'check' in the method name indicates that the method will also place text in the Infolog.

static txtNotExist

Takes no default parameters. It can take the buffer as a parameter, and should return a fully formatted error message. This is only used by the global methods checkField and warning.

Returns a TxtNotExist data type which should say that the record was not found.

See also

Common Table

xRecord Class

static find Method Design Pattern

static exist Method Design Pattern

Announcements: To see known issues and recent fixes, use Issue search in Microsoft Dynamics Lifecycle Services (LCS).