The Dynamics AX application runtime supports the following three database platforms:
SQL Server 2005
SQL Server 2008
Oracle Database 10g
However,
as mentioned earlier, you don’t usually need to focus on the underlying
database because most of the differences in the databases are
abstracted away by the application runtime. Unless an individual
database offers very specific features, you can be almost certain that
application logic developed using one database platform will execute
without problems on the other platforms.
The
Dynamics AX application runtime also supports the concurrent use of
temporary tables where data is stored in files. You use these tables
for temporary storage of records, and the application runtime uses them
to mirror database records.
Figure 1
shows how the execution of an update method on a record buffer in the
application logic results in subsequent execution of application
runtime logic. The database layer decides how to issue the correct
statement through the appropriate API based on the installed database,
the table itself, and how the table is mapped to the underlying
database.
As
shown in the diagram, database statements to the SQL Server 2005 and
SQL Server 2008 database platforms are invoked through the Open
Database Connectivity (ODBC) interface, and statements to Oracle
database 10g are invoked through the Oracle Call Interface (OCI).
1. Database Synchronization
When
tables with fields and indexes are defined in the AOT, they eventually
become tables in a database. Through its database layer, the Dynamics
AX application runtime synchronizes the tables defined in the
application with the tables in the database. Synchronization is invoked
when any of the following actions occurs:
A Dynamics AX application is installed or upgraded.
Newly licensed modules and configurations are enabled.
A table is created, changed, or deleted.
An extended data type is changed.
The
Dynamics AX application runtime uses one-way synchronization in which
the table definitions in the Dynamics AX application are the master,
and the database schemas in the database reflect the definitions inside
Dynamics AX. If the database schemas don’t match the table definitions
in Dynamics AX, the schemas are modified to match the table definitions
in Dynamics AX when the application is synchronized against the
database.
Not
all tables, fields, and indexes defined in Dynamics AX are reflected in
the database. A table is synchronized to the database if it isn’t
defined in metadata as a temporary table (its Temporary
property is set to Yes) and the associated configuration key isn’t
disabled. The configuration key could be explicitly disabled, or it
could be implicitly disabled if the associated license key isn’t
enabled. A field is synchronized to the database if the content should
be stored in the database (its SaveContents
property is set to Yes) and the associated configuration key isn’t
disabled. An index is synchronized to the database if it is enabled
(its Enabled property is set to Yes) and the associated configuration key isn’t disabled.
When
you compare a table defined in Dynamics AX to the corresponding table
in the database, the database table could contain fewer columns than
defined fields in Dynamics AX and fewer indexes than defined in
Dynamics AX. The indexes in the database could also contain fewer
columns than defined because a defined field might not be enabled,
preventing it from appearing in the database index.
Important
There
is no guarantee that the application runtime can synchronize the
database if a configuration key is disabled while there is data in the
database because re-creating the indexes could result in duplicate
values in the index. |
The
Dynamics AX runtime applies several system fields to each table, which
are synchronized to the database. The system fields are real columns in
the database tables even though they aren’t visible as columns in the
AOT. The database table could therefore contain more columns than you
see when you view the table definition in the AOT. Also, in certain
circumstances, the Dynamics AX runtime includes an extra column in a
database index to make it unique.
The Dynamics AX application runtime applies the columns shown in Table 1 to the tables in the database based on whether the following system fields are enabled on the table.
Table 1. Dynamics AX System Fields
| Dynamics AX System Field | Database Column | Table Property |
|---|
| RecID | RECID | Always |
| recVersion | RECVERSION | Always |
| dataAreaId | DATAAREAID | SaveDataPerCompany = Yes |
| createdBy | CREATEDBY | CreatedBy = Yes |
| createdDateTime | CREATEDDATETIME | CreatedDateTime = Yes |
| createdTransactionId | CREATEDTRANSACTIONID | CreatedTransactionId = Yes |
| modifiedBy | MODIFIEDBY | ModifiedBy = Yes |
| modifiedDateTime | MODIFIEDDATETIME | ModifiedDateTime = Yes |
| modifiedTransactionId | MODIFIEDTRANSACTIONID | ModifiedTransactionId = Yes |
The
Dynamics AX application runtime requires a unique index on each table
in the database to ensure that it can specifically identify each record
in the database through the use of an index. The application runtime
always ensures that at least one unique index exists on each table in
the database; if no indexes are defined on the table or they are all
disabled, the application runtime creates a RecID index as if the CreateRecIdIndex
property had been set to Yes on the table. If indexes exist but none
are unique, the application runtime estimates the average key length of
each index, chooses the index with the lowest key length, and makes
this index unique by appending the RECID column.
If you want data in the tables to be saved per company (you set the SaveDataPerCompany property to Yes), the application runtime always applies the DATAAREAID column as the first column on every index.
Note
Because
a table definition inside the Dynamics AX application is the master
definition and the database schemas are always changed to reflect the
Dynamics AX table definitions, it is difficult—if not impossible—to
attach a Dynamics AX application to an existing legacy database. |
2. Table, Column, and Index Naming
The
tables and columns in the database generally have the same name as
defined in Dynamics AX. Indexes, however, are prefixed with I_<table id>. Any index on the SALESTABLE table in the database is therefore prefixed with I_366 because the ID for the SalesTable
table in Dynamics AX is 366. The Dynamics AX application runtime allows
a maximum of 30 characters for names in the database, so if names of
tables, fields, or indexes exceed this number, they are truncated to 30
characters, including the appended ID of the table, field, or index.
For example, a table named LedgerPostingJournalVoucherSeries with an ID of 1014 becomes LEDGERPOSTINGJOURNALVOUCHE1014.
Tip
If the name method is called on a dictTable, dictField, or dictIndex object with DbBackend::Sql as a parameter, as in dictTable.name(DbBackend::Sql), the method returns the exact name in the database. |
