The post Inform Microsoft about country/region regulation changes and track the status of regulatory features appeared first on Microsoft Dynamics 365 Blog.

From time to time we see questions about the compatibility statements and what they mean. The most common question relates to whether they apply to the kernel or the application.

A common misconception is that you only need to patch the kernel rather than the application. This is not the case.

For example, If the compatibility statement says that you have to be on AX 2012 R2 CU7 in order to use SQL Server 2014, it means that you have to run your application at CU7 or higher.

As for the kernel, we generally recommend that you run a recent kernel, so in the AX 2012 R2 CU7 scenario mentioned above, you should be on kernel in the 6.2.3000.nnnn range even if your application is still 6.2.1000.4051.

You can download the latest kernel for your AX version from LCS (link below)

Always download the current version of the AX 2012 System Requirements document (link below) to ensure that you are running your environments in a supported state.

For more details on this topic, see the following:

Overview of Microsoft Dynamics AX build numbers
https://blogs.msdn.microsoft.com/axsupport/2012/03/29/overview-of-microsoft-dynamics-ax-build-numbers/

Microsoft Dynamics AX 2012 System Requirements
http://approjects.co.za/?big=en-gb/download/details.aspx?id=11094

Dynamics AX In-Market Engineering (Tag: Compatibility)
https://blogs.technet.microsoft.com/dynamicsaxse/tag/compatibility/

Dynamics AX In-Market Engineering (Tag: Compatibility Certifications)
https://blogs.technet.microsoft.com/dynamicsaxse/tag/compatibility-certifications/

FAQ: Microsoft Dynamics AX Kernel Hotfixes
https://blogs.msdn.microsoft.com/axsupport/2014/12/10/faq-microsoft-dynamics-ax-kernel-hotfixes/

LCS – Download latest kernel
https://lcs.dynamics.com/v2/LatestKernel

The post Compatibility statements – Patching the kernel only is not enough – you have to patch the application appeared first on Microsoft Dynamics 365 Blog.

Consider a scenario where you are running AX 2012 R3 and you want to import data from Excel files using ODBC. Having recently worked a case on this topic, I thought I’d share some of the details on how this can be set up.

1. Background

The main reason we were looking into this way of importing Excel data was that trying to import the data in Batch using Excel files would in some scenarios result in this error:

The version of Microsoft Excel is not supported.-Exception from HRESULT: 0xC020801C

Working with a LCS Repro VM we were able to reproduce the issue, and then establish an alternative approach that I will outline below.

There are lots of ways to import data into Microsoft Dynamics AX and this is only one of them. The best tool for the job and approach will depend on many factors, including the degree of control you have over source data formats (CSV File, Excel File, XML File, AX, ODBC), the frequency of the imports, the complexity of the entities being used, security considerations, etc.

The aim of this blog post is simply to outline one approach which you may be considering.

2. Prepare the environment

In this example, we are working with a very simple 2 column Terms of delivery entity Excel input file.

// Disclaimer:
// Microsoft provides programming examples for illustration only, without warranty
// either expressed or implied, including, but not limited to,
// the implied warranties of merchantability or fitness for a particular purpose.
// This mail message assumes that you are familiar with the programming language that
// is being demonstrated and the tools that are used to create and debug procedures.
//
// This source code is freeware and is provided on an "as is" basis without warranties of any kind,
// whether express or implied, including without limitation warranties that the code is 
// free of defect, fit for a particular purpose or non-infringing. The entire risk as to the 
// quality and performance of the code is with the end user.

A. Download the 64-bit version of Microsoft Access Database Engine 2010 Redistributable:

http://approjects.co.za/?big=en-us/download/details.aspx?id=13255

B. Copy the installer to a local folder and run the install from command line using the /passive parameter:

C:\MSFT\AccessDatabaseEngine_x64.exe /passive

C. Backup the registry and rename the key mso.dll in the following location:

Warning: Incorrectly editing the registry may severely damage your system. At the very least, you should back up any valued data on the computer before making changes to the registry.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\14.0\Common\FilesPaths

D. In Windows, create a 64-bit ODBC data source pointing to the Excel file to be imported:

E. In AX, create an ODBC source data format using the 64-bit ODBC data source created before:

F. In AX, create a Processing group using the source data format just created. The query should look like: select * from [worksheet$], for example:

Select * from [S1$]

G. In AX, generate the mapping and test:

3. Run the DIXF Excel file / ODBC source data format import as a Batch

We can now proceed and run the DIXF import using Batch processing:

The Batch job is executing:

The Batch job has ended successfully:

We can verify that the job ran as expected by checking the Execution history, too:

4. Testing

As always, ensure you’ve set up a proper Dynamics AX TEST environment first, and that you are familiar with the impact of your DIXF actions before you perform them in PROD.

The post DIXF – Importing data using Excel and ODBC appeared first on Microsoft Dynamics 365 Blog.