Troubleshooting Data Import Export Framework

As promised in my previous blog post, I would write two blog posts with a summary of my presentation at the AXUG European Congress. In this post, I will provide some tips related to troubleshooting Data Import Export Framework issues.

Known issues

There are some known issues that you should be aware of when you start using Data Import Export Framework or when you encounter some unexpected errors.

• Crash on staging preview
  When you encounter an issue where the Data Import Export Framework service crashes, you should check if your SQL Server version is correct. SQL Server 2012 R2 without at least CU2 causes this issue. You can read about compatibility in the blog from Dynamics AX In-Market Engineering.
• Version of Excel not supported
  If you are using Excel files as source and get the error that your version of Excel is not supported, you can have a look at the next blogs for support:
  http://ax2012dmfdataimport.blogspot.com/2014/05/dynamics-ax-2012-dixf-issues-and.html/
  https://blogs.msdn.microsoft.com/axsupport/2016/04/08/dixf-importing-data-using-excel-and-odbc/

for more known issues you can use Issue search on Lifecycle services.

Start troubleshooting

When running the tool, you might notice some issues when data is incorrect. Initially you don’t know if errors are related to the source file or due to a setting or bug. How would you find out what is wrong? I will try to help you with the next notes. First of all, there can be errors at several stages.

• Staging status
• Target status

To be able to determine at what stage the processing stopped, you can view the status in the form Processing history.

Staging errors

For the reproduction of this error I created a small source file for Inventory opening transactions with the next lines.

When you look carefully at the contents, you may find already some incorrect and inconsistent values, but assume you have a file with thousands of lines, you will not check the lines yourself, wouldn’t you?

When there is an error on the Staging status you would expect to view some errors in the Error log. It could be the case that this error log does not have details to be able to see what is wrong with the import. For example, the option View error file is disabled and Staging log details does not provide any details.

What would be needed to do to have details available? The answer can be found in a parameter and an import option.

On the Data import/export framework parameters you can enable the option Create error file. This option will be used as default when you start a new import.

The option Create error file is an additional option that is defaulted from the parameter setting. You can also change the setting on this step. When it is enabled, the details are captured and stored in Microsoft Dynamics AX. Note that this will have a performance penalty and would be useful for troubleshooting only. When running the import where the Create error file option is enabled, the View error file option is enabled.

When clicking this button, AX will open a file which has only the lines that have an issue.

In many cases you will not be able to note on which line which field(s) would have caused the error. So how can we find out about this?
Together with the generation of the error file, also detailed information has been captured. When you now open the Staging log details form, you will get the information about violations.

Now we know that there are issues with values in the QTY and TRANSDATE columns. On purpose, I used the comma instead of a dot for the decimal separator on one line. Also a month ’13’ does not exist. The date format depends on the Language locale field which can be set up on the Source data format.

If you have issues where the file looks fine, but no data is imported, you should check the Code page and Unicode settings on the Source data format. The source file might have another code page compared to the one that was set up in AX.

Target errors

When the staging data has been loaded successfully, you can view the staging records and validate the result manually and also use the validation to see if there would be any known errors in upfront. The above used file has been modified to correct the data type violations, but the item numbers has been edited to have items in the file that does not exist in the Microsoft Dynamics AX demo company.

Using the Validate all option, no errors were reported. If there are errors, you can import a new file or correct the data in the staging details.

As the validation is successful, the target step was executed. In this case, I got an error. You can then go to the execution history to read the error details. In this example, I got the next log.

Using the Infolog, you can view all the details. In this case, the Item ID is filled in the staging with a value that does not exist, so the data is not copied. Upon saving the record, the journal line is validated and raises this error. The error would be solved using the correct item numbers.

There is more

When using the Data Import Export Framework, sometimes you can get some other errors. This post is intended to get you familiar with the data troubleshooting. Did you also get an error “Conversion failed when converting the nvarchar value ‘XXXX’ to data type int” on a custom built entity?

If you want to learn about the cause and how to solve this, watch my next post coming. Make sure you subscribe if you don’t want to miss it!

I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.


That’s all for now. Till next time!