Blog - Page 7 of 20 - DAXRunBase

31 03, 2019

Trace database cleanup in an efficient way

By DAXRunBase|2020-03-23T13:21:53+01:00March 31st, 2019|Categories: AX 2012, Dynamics 365 for Finance and Operations|Tags: AX 2012, cleanup, database, SQL, trace|0 Comments

The Trace parser is an excellent tool for troubleshooting business functionality within Microsoft Dynamics AX 2012 and Dynamics 365 for Finance and Operations. Your Trace database can quickly grow large and it does affect the tools’ performance adversely.

Removing the old trace collections one-by-one is time consuming. You could utilize a stored procedure for cleaning up your AX trace database efficiently in SQL:

-- Replace AXTrace with your database name
USE [AXTrace]
GO
 
-- Truncate transaction log to reduce size
DBCC SHRINKFILE (N'AXTrace_log' , 0, TRUNCATEONLY)
GO
 
-- Iterate through the list of traces in the database
DECLARE cur CURSOR FOR 
       SELECT [TraceId] FROM [dbo].[Traces]
 
DECLARE @Id AS int
 
OPEN cur;
FETCH NEXT FROM cur into @Id;
 
-- Remove all traces in the database with the DeleteTrace stored procedure
WHILE (@@FETCH_STATUS = 0)
BEGIN
       EXEC [dbo].[DeleteTrace] @TraceId = @Id
       FETCH NEXT FROM cur into @Id;
END
 
CLOSE cur;
DEALLOCATE cur;
 
-- Truncate transaction log to reduce size
DBCC SHRINKFILE (N'AXTrace_log' , 0, TRUNCATEONLY)
GO

31 03, 2019

Checklist can change AX configuration keys

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

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.

18 10, 2018

Synchronize Models between workspaces in MSDyn365FO

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

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.

15 10, 2018

Developer VM performance for MSDyn365FO

By DAXRunBase|2018-10-15T13:00:43+02:00October 15th, 2018|Categories: Dynamics 365 for Finance and Operations, MSDyn365FO|Tags: #MSDyn365FO, Azure, benchmark, D365FO, Dynamics 365, HDD, performance, SSD, storage, VHD, VM|0 Comments

When you are used to snappy desktops or locally hosted virtual machines and suddenly you need to move to the cloud, you would expect to see similar capabilities for a reasonable price. Unfortunately that was not my experience when it comes to deploying AX 8.1 in Azure cloud. This post is about setting expectations straight for MSDyn365FO developer VM performance hosted in the cloud vs. locally.

First of all, when you deploy your developer VM on the cloud, you have two options. Standard and Premium, which is a reference to what kind of storage will be allocated to your machine. The default size is D13 (8 cores, 56 GB RAM) for regular rotating hard disks, and you need to use the DS-prefixed computers for the flash storage with memory-optimized compute. You can read up about them on these pages in more detail on the Microsoft Docs site:

Premium disk tiers
Virtual machine sizing

When it comes to premium performance, the Virtual Machine template that Microsoft has built for the LifeCycle Services deployment is using the following structure:

Purpose	Tier	IOPS	Throughput
Operating System	P10	500	25 MB/sec (50K reads)
Services and Data	P20	2300	150 MB/sec (64K reads)
Temporary Build	P10	500	25 MB/sec (50K reads)

(more…)

5 10, 2018

Find standard code overlayering in Dynamics 365 FO

By DAXRunBase|2020-03-23T13:44:50+01:00October 5th, 2018|Categories: Dynamics 365 for Finance and Operations|Tags: #MSDyn365FO, AX 8.1, D365FO, Dynamics 365, extension, metadata, overlayering, reflection, upgrade, XML, XPath, XQuery|0 Comments

We are preparing for the code upgrade from AX 2012 R3 to D365FO 8.1, the latest version recently released. As you know it is extensions-only, meaning we are not allowed to modify any of the standard objects directly. I would strongly suggest to familiarize yourself with Extensions if you are planning to go down this journey as well. An important part of this is that you need to send in Extensibility requests via LifeCycle Services, for code that cannot be moved to a pre- / post-event handler. Our large number of customized methods came out well above 1000+ overlayered objects when we ran the LCS code upgrade tool on our modelstore. We had to find standard code overlayering of all methods to narrow down the search on what should be inspected for extensibility.

I have been exploring the options to use the MetaData API for extracting package information of methods. We wanted to find any methods, which belongs to both a standard, and a custom package, like ApplicationPlatfrom and ApplicationPlatform.JAD (our module). That did not lead to anything useful other than realizing that you can only access such details up to the root node level (table, class) currently. Here is the code piece for partial results:

(more…)