Development III training, Day 2

I am back with my notes from development III training.

Today was ‘interesting’ since the trainer would tell us things that are not true with the hope that it will encourage us to test and figure things out for ourselves.

I guess it’s a good strategy to get us to become better critical thinkers and self-learners. It has left me with a whole list of things to try for myself since I have stopped believing anything he says.

Without further ado, here are three things I learned today:

Create a project with all the temporary tables.

If you want to create project with a list of all the temporary tables in the AOT, you have a few options:

1. Create a new project and use the project filter to filter tables that contain ‘tmp’ in the name. Keep in mind, that this method assumes that all temporary tables contain ‘tmp’ in the table’s name (This might be a best practice, but someone could have ignored it.)

Another problem with this method above is that it is not dynamic. If you create a new temporary table outside of the project, it will not be added to the project automatically.

2. Create a tables node in a project and set its Group Mask property to ‘tmp’. This will create a filter for the tables node so that it contains all the tables that contain ‘tmp’ in the name.

This still does not solve the problem that another developer can create a normal table called MytmpDataTable or a temporary table named MyData . The group mask still only filters on the table name.

An advantage with the group mask is that the tables are dynamically added. Any new or renamed tables will be added to the tables node in the project.

While the temporary table example clearly has drawbacks, you can still use the group mask function when you want to filter based solely on a object’s name. For example, you could create a module project that contains all tables starting with ‘EcoRes’ or ‘Hcm’.

3. The third, and best option (in my opinion) is to create a job that checks each table’s properties and if it is a temporary, it added to a project.
   This assures that all the tables in the project are really temporary tables, and it is ‘dynamic’ since you can always rerun the job.

The AX database model
In general the AX data model is a normalized data model. One of the exceptions is the Parm tables. Parm tables are based on a Star(or snowflake) model.

In practice this means that they improve performance, reduces locking of important records but contains duplicate data also found in other tables.

Since all the data in the parm table is stored in other tables in the system, the data can be deleted since it can always be recreated with its source table’s status is changed.

Server client void..
I noticed this method during class:

Adding the sever method modifier forces the method to be run on the server, while adding client does the same but for the client. So how can you force a method to run on both the client and server?

Turns out “you can use both client and server to change the execution place (to Called from) of a class static method or to document that it is decided that a table method executes best as Called from”.

Of course the server and client method modifiers can only be used on static and table methods. If the method is not static, you need to specify the location using the class property RunOn. Non-static class methods run where their class was instantiated.

AX Game design
We received an assignment to write a game with the concepts we learned in class like the map class, tmp tables and sets. I’ll be back to share my version of ‘Hangman’ in Dynamics soon!

If you have questions about these topics I would love to discuss them in the comments.