5. Dynamics AX Type System vs. Database Type System
Because
Dynamics AX application table definitions are the master for the table
definitions in the database, the Dynamics AX application runtime also
explicitly controls the mapping between the Dynamics AX data types and
types in the supported databases. Table 2
describes the mapping between the Dynamics AX type system and the
database type system. The Dynamics AX application runtime doesn’t
support database types not shown in this table.
Table 2. Dynamics AX and Database Type Systems
| Dynamics AX | SQL Server 2005 | SQL Server 2008 | Oracle Database 10g |
|---|
| int | INT | INT | NUMBER(10,0) |
| real | NUMERIC(28,12) | NUMERIC(28,12) | NUMBER(32,16) |
| string (fixed length) | NVARCHAR(length) | NVARCHAR(length) | NVARCHAR2(length) |
| string(memo) | NTEXT | NTEXT | NCLOB |
| date | DATETIME | DATETIME | DATE |
| time | INT | INT | NUMBER(10,0) |
| utcdatetime | DATETIME | DATETIME | DATE |
| enum | INT | INT | NUMBER(10,0) |
| container | IMAGE | IMAGE | BLOB |
| guid | UNIQUEIDENTIFIER | UNIQUEIDENTIFIER | RAW(16) |
| int64 | BIGINT | BIGINT | NUMBER(20,0) |
6. Database Log and Alerts
Dynamics
AX includes two features that base their functionality on the fact that
data has been manipulated in tables: the database log and alerts. Both
features use information the Dynamics AX application runtime exposes
when specific data is manipulated and when the application runtime uses
configuration data entered into a Dynamics AX framework table from the
application. The configuration that identifies which statements to
trace and log is stored in the Databaselog
table provided by the application runtime. When a statement that should
be traced and logged is executed, the application is notified by
executing a callback method on the Application class.
Figure 3 illustrates a scenario in which Dynamics AX is configured to log updates to custTable records. When the custTable.update method is called, it invokes the base version of the update method on the xrecord object by calling super.
The base version method determines whether database logging has been
configured for the given table and the update statement by querying the
Databaselog table. If logging is enabled, a call is made to the logUpdate method on the Application object, and the X++ application logic inserts a record into the SysDataBaseLog table.
The
scenario is the same for inserts, deletes, and renaming of the primary
key as well as for raising events that triggers alerts.
You can use the application runtime table Databaselog to configure all the logging and events because it contains a logType field of type DatabaseLogType, which is an enumeration that contains the following four values for the database log feature: Insert, Delete, Update, and RenameKey. It also contains the following four values for alerts: EventInsert, EventDelete, EventUpdate, and EventRenameKey. When the application runtime queries the Databaselog table, it therefore queries for the configuration of a specific type of logging on a given table.
Table 3
shows the correlation between the database log and alert configuration.
It shows what triggers the log or event, which method on Application the callback is made to, and to which table the log or event is logged.
Table 3. Database Log and Alert Implementation Details
| Logged Event | Triggering Method on Xrecord Class | Callback Method on Application Class | Where Logged |
|---|
| Database insert | insert | logInsert | SysDataBaseLog |
| Database update | update | logUpdate | SysDataBaseLog |
| Database delete | delete | logDelete | SysDataBaseLog |
| Database rename primary key | renamePrimaryKey | logRenameKey | SysDataBaseLog |
| Insert event | insert | eventInsert | EventCUD |
| Update event | update | eventUpdate | EventCUD |
| Delete event | delete | eventDelete | EventCUD |
| Rename primary key event | renamePrimaryKey | eventRenameKey | EventCUD |
Note
The application runtime doesn’t query the Databaselog
table in the database every time a trigger method is executed because
the AOS caches all records in memory when first needed. When records
are changed in the Databaselog table, the cached version must be flushed. To flush the cache, call SysFlushDatabaseLogSetup::main
from X++, which not only flushes the cached memory on the current AOS
but also informs other AOSs that they should flush their caches as
well. The other AOSs read the flushed information from the database at
predefined intervals, so they are flushed with minor delays. |
