Effect of Disabling configuration Key on tables

You can disable a regular persisted database table by disabling the configuration key that controls the table. Disabling the key causes the system to automatically create a TempDB style of temporary table that matches the fields and schema of the database table. This temporary table exists in the underlying SQL Server database and is managed by the Application Object Server (AOS).

The purpose of automatically creating this TempDB table is to enable AOT objects that reference the disabled table to continue to compile and run. You can read and write to this TempDB table even though the configuration key is disabled.

All table buffer variables inherit the methods of the xRecord class. One such method is setTmp, which creates an InMemory temporary table that has the same schema as the regular table. However, the setTmp method cannot create an InMemory table from a TempDB table. You can call the method isTempDb to determine whether the setTmp method is available.

Update PackingSlip number after Purchase Order PackingSlip  in Ax 2009

There are mainly four tables that has the old PackingSlip number 

VendorPackingSlipJour 
VENDPACKINGSLIPTRANS
INVENTTRANS
VENDPACKINGSLIPPURCHLINK

If we update these tables by querying for Purchase Id then the PackingSlip would be updated with the new number 

Inventory Dimensions in Ax :

  The Various Inventory Dimensions are :

 

• Configuration

• Color

• Size

• Site

• Warehouse

• Location

• Pallet ID

• Batch number

• Serial number

All these inventory Dimensions are configured in three Dimension groups :

• Product dimension group: Configuration Color Size
• Storage dimension group: Site Warehouse Location Pallet ID
• Tracking dimension group : Batch number Serial number

All the inventory Dimensions are configued under one Dimenstion group in earlier versions of Ax 2009. In Ax 2012 the dimensions are grouped differently based on the nature of the dimension and its usage.

WorkFlow Performance issues in Ax 2009

I recently came across a performance issue with WorkFlow Configured for Purchase Orders in Ax 2009. As we all know that WorkFlow can be setup  at various Functions like Purchase order/Sales Order etc..  
(Please refer to this URL if you need more information
http://msdn.microsoft.com/en-us/library/cc585061(v=ax.50).aspx)

Our client had setup the workFlow for Purchase Order. The entire configuration was fine and the system was working fine with various workFlow Conditions that were setup during the creation of Purchase Order. 
When the user started adding more items in a purchase order then the system started performing slowly. For Example. if we have around 200 items under the same purchase order, then work Flow would have to loop through all the 200 items to see which condition is met and which WorkFlow Configuration was a success. The problem that i found  was the system is looping through all the 200 items and also through each workFlow Configuration.This is because the WorkFlow is designed in such a way that if one of the workFlow Configurations are met then system still look for all other workFlow Configurations that might also succeed. Then the system would evaluate the best configuration based on the Default setting that is setup in workFlow Configuration. So this led to the vast amount of time being consumed in evaluating the valid WorkFlow for a particular Purchase Order. 

The Solution for this as a workAround was to exit when ever the System finds the valid workFlow Configuration so that it does not have to loop through all the configurations. The work around was mainly done because our client does not have duplicate workFlow configurations. This was basically driven a parameter that is setup in Account Payables to see whether we need drive the WorkFlow Configurations single or multiple. 
The changes have been done in 

Classes --> WorkFlow --> findWorkflowConfigToActivateForTemplate method where the system would look for a valid configuration.

I hope you find this information helpful. Any new thoughts would be appreciated.

Label Import Problems in Ax

When you are importing XPO which contains new labels from Partner or external parties ,the default action will be set to Make a New Label which would eventually create a new labelID prefix with the default label file that is set in our "Create Labels in the Label File" dropdown.  This leads to old label id  not being shown in the forms where it is pointing. In order to avoid these problems always Select "Import Label" which would import the label from the XPO  with the same label id and drop in the correct label file.

Display hour glass during a lengthy operation in Ax

Before the start of our execution of lengthy code we need to place the below code

startLengthyOperation();

// your code here 

And after the end  of the code we need to place 

endLengthyOperation(); 

This will enable the form to show hour glass until the code is executed.