synchronize Archives

Checklist can change AX configuration keys

The other day we ran into a serious issue during our regular Production system maintenance. The Data dictionary synchronization step has started creating indexes with a DEL_ prefix on large tables such as InventTrans. We have quickly identified that AX configuration keys got changed by opening a checklist.

It turned out that some of the users had the System_Checklist security privilege assigned, and they have clicked it by accident. Standard code can add or update License configuration keys when you run the checklist.

In our case only a couple of new entries were activated, such as SysObsoleteObjects60. It has added a lot of DEL_ objects which could be easily rolled back. At another company it has done irreversible damage for inventory dimensions. You could imagine how bad the situation could get if important config keys are turned off. Synchronization would start dropping columns and entire tables.

The quick fix was to use the Export functionality on the License configuration form from our Quality Assurance AX (daily copy of Production). Then we could import the correct configurations to Prod and revert changes by doing a Data dictionary synchronization.

Please ensure that your users only have access to security privileges they really need, to avoid unintentional damage. Remove the System_Checklist and similar features from everyone, except the administrators.

By DAXRunBase|2019-03-31T11:32:46+02:00March 31st, 2019|Categories: AX 2012, Dynamics 365 for Finance and Operations|Tags: #MSDyn365FO, AX 2012, dictionary, synchronize|0 Comments

Synchronize Models between workspaces in MSDyn365FO

For our upgrade project we have decided to create 4 packages/models to start with, which is enough to separate larger areas. Once the models have been created on my VM, I had to make it available for everyone. The goal was to synchronize models between workspaces of other developers.

Package / Model	Description
JAD Core	Core application framework changes, essentially what is in Platform and Foundation
JAD Operation	Business application customizations, later on we might create additional models for larger functionality
JAD Integration	For exchanging
JAD Reporting	For reporting, data warehousing, CDS and entities

The devil lies in the details and for some reason the model was not showing up after synch. It turns out that the model description sits in an XML file within the Descriptor folder. You need to manually include it in source control, as explained in the documentation as well. Once it is checked in, all you need to do to synchronize models between workspaces is to get latest changes, then click on Dynamics 365 > Model Management > Refresh models.

By DAXRunBase|2018-10-18T09:48:24+02:00October 18th, 2018|Categories: Dynamics 365 for Finance and Operations, MSDyn365FO|Tags: #MSDyn365FO, AX 7, AX 8, Azure DevOps, D365FO, Descriptor, Dynamics 365, synchronize, VSTS|0 Comments

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

SQL data compression for Dynamics AX 2012 (Part 1)

Data compression for tables and indexes are beneficial, especially for large tables within your SQL DB, where you are doing more read operations than writes. In Microsoft Dynamics AX you are advised to do this via the client, otherwise your settings would be lost during the Data Synchronization.

Unfortunately there is another case of hardcoded value from Microsoft, the SysSQLSetupHelper class is checking the version and the edition of SQL Server. Since Compression is a feature supported by version SQL Server 2008 (v10) and up, the code needs to be changed to cater for SQL 2012+ as per below:

(more…)

By DAXRunBase|2015-11-23T17:46:24+01:00October 14th, 2015|Categories: AX 2012|Tags: AX 2012, compression, metadata, SQL, synchronize, tables, X++|1 Comment

Silent metadata synchronization

When we use the Microsoft Dynamics AX command line parameters to trigger a startup command with running the client, it is a very common situation that our metadata is altered.

There could be many scenarios where the metadata change requires user interaction (like a possible index violation, removing fields, etc) on a form, where you could review the changes before it is permanently committed to the database. This is not ideal if you would like to do automated tasks, like running a workflow step on a Team Foundation Server build controller (code / metadata synchronization, XPO import).

Fortunately there is a way of suppressing this user interaction, by setting a global variable.

(more…)

By DAXRunBase|2015-11-23T17:51:14+01:00December 12th, 2012|Categories: AX 2012|Tags: AOT, AX 2012, cache, metadata, synchronize, tables, TFS, X++|0 Comments