Share via


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

Description

aosValidateDelete

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

aosValidateInsert

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.

aosValidateRead

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

aosValidateUpdate

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

caption

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.

clear

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.

Note

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.

delete

Executed when a record is deleted.

equal

Executed when you compare tables.

helpField

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.

initValue

Executed when a new record is added.

initValue is automatically called from forms.

insert

Executed when a new record is inserted into the table.

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

merge

Executed when two records are merged.

modifiedField

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.

postLoad

Executed when a record has been loaded.

renamePrimaryKey

Executed when the table's primary key is renamed.

reRead

Executed when a record is re-read.

toolTipField

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

toolTipRecord

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

super() in toolTipRecord calls caption.

update

Executed when an existing record is modified.

validateDelete

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.

validateField

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.

validateWrite

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.

write

Persists a record to the table.

xml

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

Description

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