Tables as Data Types :MICROSOFT DYNAMICS 365:DYNAMICS AX 2012 X++

Tables as Data Types

All tables, which are created in MorphX by using the Application Object Tree (AOT), can be treated like class definitions (at least in all practical aspects) in the X++ programming language.

You can address fields and create methods on tables. The methods can be invoked on instances of the table.

To manipulate (read, update, insert, and delete) records in tables, you must declare at least one table variable, which can hold the record in focus.

Here are a few important differences between tables and objects:

·         You cannot allocate space for table variables—it is done implicitly.

·         Fields in table variables are public—you can reference them anywhere.

·         Fields in table variables can be referenced with expressions.

Scope of Table Variables

Table variables are declared on the basis of the data dictionary in MorphX; that is, on the basis of the tables, which are declared in the AOT. In most respects, table variables can be considered objects. Contrary to objects, they are not allocated explicitly. Only a variable declaration is required.

All tables are compatible with the Common table in the same way that all objects are compatible with the Object class. Table variables, which are declared as common buffers, can be used to hold data from any table. You cannot access tables without table variables.

Declaration of Table Variables

The principles for declaring table variables and objects are the same except for the allocation of space.

Table variable declaration

= ( tablename | common ) Variable { , Variable } ;

public void myMethod()

{

    // Declares and allocates space for one CustTable record

    CustTable custTable;

}

Note

It is a best practice to use the name of the table as the name of the variable, but with an initial lowercase letter.

Referencing Table Variables

The syntax for referencing fields in a table variable is:

RefTableVariable = Tablevariable.[ ( expression ) | fieldname ]

The most widely used field reference is Tablevariable.Fieldname, for example custTable.AccountNo.

public void printAccountNo();

{

    CustTable custTable;

    ;

    print custTable.AccountNo;

}

The syntax, however, also allows various possibilities for referencing fields in records, for example by using the TableName.(FieldId) syntax. The following example prints the contents of the fields in the current record in the Customer table.

X++

public void printCust()

{

    int i, n, k;

    CustTable custTable;

    DictTable dictTable;

    ;

    dictTable = new DictTable(custTable.TableId);

    n = dictTable.fieldCnt();

    print "Number of fields in table: ", n;

    for(i=1; i<=n; i++)

    {

        k = dictTable.fieldCnt2Id(i);

        print "The ", dictTable.fieldName(k), 

            " field with Id=",k, " contains '", 

            custTable.(k), "'";

        pause;

    }

}

Note

The previous example uses the fieldCnt and fieldCnt2Id methods. The fieldCnt method counts the number of fields in a table, while fieldCnt2Id returns the ID for a field number. For example, you can use the fieldCnt2Id method to find out that field number 6 in a table has the ID 54. It is necessary to perform this conversion because it is not guaranteed that the IDs of the fields in a table are consecutive.

Automatic Conversion

There is no automatic conversion, but table variables that are declared as Common can hold data from any table.

CONVERSION OF DATA TYPES : NULL VALUES FOR DATA TYPES :MICROSOFT DYNAMICS 365:DYNAMICS AX 2012 X++

Conversion of Data Types 

The automatic and explicit conversions that can be carried out between different data types are listed in the help topics for several of the primitive and composite data types. This topic describes the rules and algorithms that MorphX uses to perform automatic (or implicit) type conversion on primitive data types.

The default values and the internal representation for variables of primitive data types in X++ are shown in the following table.

Data type	Default	Internal representation
Boolean	false	Short number
Integer	0	Long number
Real	0.0	BCD (binary-coded digital) number
Date	Null	Date
String	empty	List of characters
Enums	0 (first entry)	Short number

The internal implementation is shown to explain the automatic type conversions that X++ can perform. The principle is simple: every number can automatically be converted to another number in an expression. Usually, the conversion is upward; that is, from short to long to BCD. The conversion follows the operators in the expression. The following table shows the rules.

Operator	Description
+ - *	If one of the operands is a real, the other will be converted into real and the result is a real. If both are integers, Booleans, or enums, no conversion will take place, and the result will be integer, Boolean, or enum, respectively. Otherwise, a Boolean is promoted to enum and enum is promoted to integer
/	Because / is division, the result can be decimal. X++ converts numbers to real before performing the division. The result is real.

Conversion Examples

In the examples shown in the following table, which illustrate these principles, the first letter of the data type is used as a variable identifier (b is a Boolean, d is a date, I is an integer, r is a real, and s is a string).

ID	Expression	Left data type	Operands converted	With numbers	Result
1	i = b + b	integer	Boolean, Boolean	i = false + false	0
2	i = r + b	integer	real, real	i = 33.3 + true	34
3	b = i + r	Boolean	real, real	b = 10 + 33.3	undefined
4	b = i + r	Boolean	real, real	b = 0 + 1	true
5	r = i + b	real	integer, integer	r = 100 + false	100.0
6	r = i + b	real	integer, integer	r = 100 + true	101.0
7	i = r MOD b	integer	integer, integer	i = 33.3 MOD true	0
8	r = i DIV i	real	no conversion	r = 100 DIV 5	20
9	d = d + i	date	date, date	d = 1\1\1998 + 30	31\1\1998
10	i = d + i	integer	date, date	i = 1\1\1998 + 1	compile error
11	d = d + d	date	date, date	d = 1\1\1998+1\1\1998	compile error
12	s = s + s	string	string, string	s = "a" + "b"	"ab"
13	i = s + i	integer

Notes for the Preceding Examples

The following table discusses details about some of the rows in the preceding table. The ID values match.

ID	Discussion
2	The assignment i = r + b, with r = 33.3 and b = true is calculated as follows: X++ i = 33.3 + true; // Which is evaluated as... i = 33.3 + 1.0; // Which is evaluated as... i = 34.3; // Which is evaluated as... i = 34; // ...as i is an integer.
3	The result is undefined because a Boolean has only two legal values: false (0) and true (1). The result of the expression 10 + 33.3 is 43, which is assigned to the Boolean. Note Because the internal representation is integer, you can use the Boolean in an expression and it will represent the value 43. The Boolean will be considered true.
9	Shows that an integer can be added to a date. The system treats the integer as a quantity of days. Note The utcdatetime data type does not support arithmetic operations and implicit conversions. Instead, methods on the DateTimeUtil class can be used.
10	Results in a compiler error, because a date cannot be automatically converted into an integer.
11	Shows that you cannot add dates together.
12	Shows that the + operator strings concatenates two strings to create a new string.
13	Shows that there is no automatic conversion between strings and integers (or other numbers). However, you can make explicit conversions by using built-in conversion functions, such as the str2int function.

Null Values for Data Types 

Microsoft Dynamics AX does not support the concept of null values that is available in many other Database Management Systems (DBMS). A field in Microsoft Dynamics AX always has a type and a value.

For each data type, however, one value is considered null (for example, when the validateField table method is executed).

Type	Value treated as null
Date	1900-01-01
Enum	Element with its value set to 0.
Integer	0
Real	0.0
String	An empty string
Time	00:00:00
Utcdatetime	Any value with its date portion as 1900-01-01 is treated as null, regardless of the time portion value. Therefore the value 1900-01-01T22:33:44 is treated as null. Note Any utcDateTime value with its date portion as 1900-01-01 is displayed as blank by the X++ print statement. Only the value 1900-01-01T00:00:00 is displayed as blank by the Global::info method. That is the value from the DateTimeUtil::MinValuemethod.

As a result, when the validateField method checks whether a user has entered a value in a mandatory field, 0 is not accepted in an integer type field, the first entry is not accepted in an enum type field, and so on.

Also, the values that are listed in the previous table yield false in a Boolean comparison, in X++ SQL. In non-SQL X++ statements, the equal and relational operators work with these values the same normal way that they work with other values.

Variables of type container, and classes and variables of table type can be null in the traditional DBMS sense. A table type is null if all its fields have their null value.