As promised in my previous blog post, I would write two blog posts with a summary from my presentation on the AXUG European Congress. In this post I will provide some tips related to troubleshooting Data Import Export Framework issues.
There are some known issues which you should be aware of when you start using Data Import Export Framework or when you encounter some unexpected errors.
for more known issues you can use Issue search on Lifecycle services.
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.
To be able to determine at what stage the processing stopped, you can view the status in the form Processing history.
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 which 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 exists. The date format depends on the Language locale field which can be setup 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 setup in AX.
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 knows 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 were 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 exists, 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.
When using 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!
That’s all for now. Till next time!