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