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 removed from t

If you are a senior developer on Dynamics AX, you may wonder how come these issues still exist. This is the reason why I decided to write this article. Developments are now shared among diverse team, sometimes across multiple partners and outsourced to vendors, meaning different skills and processes. Therefore such well known issues still remain in production when customized best practices rules and internal review are not properly defined. The following list is not exhaustive and is only based on our experience from the field. 1. Wrong caching leads to unnecessary database calls This is one of the most fundamental feature of the product today. The three tiers architecture of Dynamics AX allows you to define caching on AOS and client. Not using caching properly is the first root cause for performance. Make sure the following rules are defined: All your customized tables have relevant table group defined in AOT. For example, master data should have “Main” category and transact