The below script can be used to update all address displayed, ensuring any changes to the address format are reflected in all address data.
When you import an AXModelStore into AX2012 you will encounter the model database log file growing to many gigabytes. Microsoft’s recommendation is to make the log file for the model store database at least 60GB.
If you are not creating a temporary scheme and just doing a full release, then there are a couple of tricks you can use to reduce this explosion of log file size.
When processing sales order, or purchase order, posting you can control the summary updates. If you go into Accounts receivable->Setup->Accounts receivable parameters, then go to the tab, summary update, and press the summary update parameters, you can change the summary update fields.
If however the field you want is not present, you can add additional fields. This is done from the AOT, under the table SalesTable for sales orders, and PurchTable for purchase orders. Add the additional fields to what to use under the field group ‘SummaryUpdate’.
If you have tried to batch print sales order picking lists in DAX2012R2, you might have encountered an issue where the picking lists would generate, but the printing would not not generate.
The test to ensure the batch server is setup correctly to be able to print, is to reprint an already created picking list on the batch server, if this prints fine then the setup is good, and the problem is the possible the same as I have encountered.
There are a few things to think off when writing code, design requirements and performance. If we include the thought process of performance when developing we can often improve our overall code performance at the time of writing.
When setting up a new system, people tend to spend lots of time setting up the various modules and creating user account. But what is often forgotten is to create employee records and link them to the users.
Below is a quick job that will create employee records for each user account, and link them. This script works on the basis that the user accounts have been allocated to the correct company as their default, and the name is the first and last name of the person. It also can filter out pre-defined users, and users allocated to company DAT, to hopefully get a clean employee set.
It is useful to be able to link the DAX session numbers with the SQL SPID, especially if you want to diagnose who is causing locks, or long running queries. This is one method to get the information.
Before you can link the two pieces of information you need to enable an extra mode on the AOS server(s). On each AOS you want to review the DAX sessions against the SQL SPID you need to complete the following setup.