AX 2012 Archives - Page 5 of 12

Picking list registration performance

We recently have implemented a new Picking application in our warehouse. Our slow performing statement e-mail has immediately highlighted that with our data volume the WMSOrder and SalesTable records were underperforming, taking 5+ seconds each time when the form was opened (close to 20). We needed to fix the Picking list registration performance.

WMSOrder

Apparently it is a standard AX form and table, but the link which they have been using is incorrectly defined, resulting in an InnerJoin for SalesTable unnecessarily.

Picking list registration performance

Also the field used for the join has no index, you should create one for WMSOrder.InventTransRefId to gain more performance.

After the adjustment it looks much better and performs really fast:

WMSOrder

By DAXRunBase|2018-02-27T10:22:18+01:00February 27th, 2018|Categories: AX 2012|Tags: AX 2012, performance, SQL, statements, tables, X++|0 Comments

Add call stack to InfoLog messages

The main communication channel for our ERP users in case we want to tell them something is via the InfoLog messages within Microsoft Dynamics AX. In case we get an error or a warning, the technical staff does not receive the details required to troubleshoot the issue much easier. In this post I would like to show you how to send the X++ or .Net CIL call stack to InfoLog messages.
Microsoft already has an article on this for AX 2009, but that was before the AX 2012 IL code execution for server-side code, so it needs slight adjustments.

https://blogs.msdn.microsoft.com/axsupport/2010/08/02/how-to-send-the-callstack-to-the-infolog/

My changes got the following improvements:

Can handle X++ and CIL execution.
Users only see the call stack when clicking the message line due to filling it with whitespace.
Specific users could be excluded from receiving the call stack, we are doing this for our service accounts such as the batch execution account. We are also excluding our eCommerce portal customers from seeing a call stack, which are the Claims-based users.
Current database server/name and user account is included in the message, in case we are storing the errors in the Event log and would like to know who had the problem.

Here is the example output:

(more…)

By DAXRunBase|2020-03-23T13:50:07+01:00July 20th, 2017|Categories: AX 2012|Tags: alerts, AX 2012, call stack, GitHub, InfoLog, X++, XPO|0 Comments

Troubleshooting batch jobs in AX

If your batch jobs are seemingly not executing in Microsoft Dynamics AX, there could be a multitude of reasons. This guide will help with troubleshooting batch jobs in AX by listing the possible causes and providing solutions for each points.

Initial setup

It is important to define what is a batch job first:

A batch job is a process which will carry out specific tasks at a certain date and time running as a background process within the AX Application Object Server service.

We need to tell the system what is the process that we want execute, which consists of a Batch job as a header, and at least one Batch task which is the actual processes running. The batch jobs can be grouped together by their roles with the help of a Batch group. If none is provided, it would still classify as one called the “Empty batch group”.

(more…)

By DAXRunBase|2017-09-25T19:51:42+02:00July 2nd, 2017|Categories: AX 2012|Tags: AX 2012, batch jobs, compile, debug, kernel, users|1 Comment

Fix Table and Field ID synchronization conflicts in AX

It is a very common issue when we change metadata in a source/build environment incorrectly that the Production environment’s AX database field identifiers are getting out of synch from our Application Object Tree (AOT). This can typically happen during a code upgrade scenario (after applying a hotfix or a new ISV solution), or if a field/table has been deleted (because for some reason we did not want to rely on the SysDeletedObjects6X configuration key: https://technet.microsoft.com/en-us/library/dn793968.aspx). In this post I would like to share my latest code to Fix Table and Field ID synchronization conflicts in AX.

The kernel is storing your current data DB’s object identifiers from your AOT (your ModelStore in the _model DB) in a table called SQLDictionary. When you do metadata object changes and release the ModelStore to your other environments, AX allocates new Object Identifiers sequentially per TreeNode type. For example the Tables are from the same range of IDs, but the Fields subnode of the Tables are starting from the same sequence for each table. You can verify this in SQLDictionary by checking TabId and FieldId values for them.

Before you attempt to Synchronize your Data Dictionary after the ModelStore release, the first step should be to run an ID conflict fixing tool. Once the IDs in the SQL Dictionary are matched with your AOT, it is safe to start synchronization. You get a visual feedback on the ID fixing tool’s progress as per below, and it finishes relatively fast:

You may read up about the issue in a bit more on the following link and have a look at how others were approaching the problem.

http://daxdude.blogspot.com/2012/12/table-ids-out-of-sync-remediesprevention.html

The Fix Table and Field ID synchronization conflicts in AX job and the class behind is available on the DAXRunBase GitHub:

https://github.com/DAXRunBase/AX-2012-R3/tree/master/Fix%20Table%20and%20Field%20ID

By DAXRunBase|2017-06-26T15:53:42+02:00June 26th, 2017|Categories: AX 2012|Tags: AX 2012, metadata, ModelStore, SQL, SQLDictionary, synchronize, tables, X++|0 Comments

Do not update AX database tables from SQL

This requirement keeps popping up on the Community Forums by people who are not familiar of how Microsoft Dynamics AX works, typically for third-party integration, data warehousing and reporting scenarios. In this post I would like to give some insights on why is it not recommended to update AX database tables from SQL.

Record identifiers

Each row in Microsoft Dynamics AX database within Microsoft SQL Server has a unique identifier which is by default the primary/surrogate key as well for the records. The field is called RecId, and it is maintained as an incremental, int64-based positive or negative number. The highest number I was able to allocate is 3 below the maximum value of a 64-bit integer, which was 9,223,372,036,854,775,805 and you would get an error for the next value:

If you would ever reach the maximum value, the manual fix is to set the next value to be -9,223,372,036,854,775,807.

(more…)

By DAXRunBase|2018-09-11T11:51:54+02:00June 13th, 2017|Categories: AX 2012|Tags: AOT, AX 2012, cache, DIXF, metadata, RecId, SQL, statements, tables, X++|0 Comments