Learn Dynamics 365 Finance and Operations(Axapta)

Today we will talk about the objects' IDs and SQLDictionary table from SQL Server. Each object in AX (mainly classes,  tables and the columns, with the emphasis placed on tables and columns right now, since that is what gets committed in SQL Server) gets an ID in order to identify them. In AX 2012 the ID is allocated at the moment of the object's creation in the ax system (either through a xpo import, new object in AOT, or model import). Now, how does AX works with the tables in the SQL Server? The system will take the definition in the AOT and will commit that (the columns, their name, lenght, type) in SQL. So far, everything is going ok, but how is AX keeping track of what it has in the SQL Server? Matching the names of the objects would be enough? Let's see.  A table in SQL could be matched by it's name in the AX AOT. So, imagine that there is a change in a table's name, or easier, for the moment, a table column's name, going from colA to colB. The table, on...

Do not place code in a form unless you cannot place it in a class or in a table method. Code written on forms cannot be reused and is difficult to customize. A class that processes all the logic in a form should have the same name as the form with "Form" as the suffix. If you have a complex form, create a class for server-related tasks. This class should have the same name as the form, but with "Server" as the suffix. If you have code in the form, the code should be for making only simple changes to the appearance of the form or to the form’s query. Try to place the code on the form or on the data source. Place code directly on controls only when you are absolutely certain that there is no other solution, and then use the AutoDeclaration property on these controls. Reasons for Removing Code from Forms ·         Forms are entirely client-based. There should be no code in them that manipulates the database (business logic). The code should be ...