Microsoft Dynamics AX Support

This blog contains posts by the Microsoft Dynamics AX Support Teams Worldwide

Virtual Company considerations for Upgrading to Microsoft Dynamics AX 2012

Virtual companies are used to share data, such as setup and master table data, between multiple companies in the system. With Microsoft Dynamics AX 2012, several key areas of the system were transformed so that the data stored is automatically shared across companies, eliminating the need for virtual company sharing.  These areas include but are not limited to Global Address data, Inventory Product data, Ledger Accounts and Dimensions.There are many scenarios where the use of virtual companies to share other data in the system will cause some modifications to be required in the upgrade code.

The following list outlines the different areas where virtual companies can have an impact:

  • Upgrade Readiness Checks:
    • Will identify all tables shared in a virtual company, and will suggest which Shadow tables need to also be shared
    • Uses a built in table list to help signify which areas of the upgrade code already handle virtualization and which tables might need to be investigated for additional coding in the upgrade scripts. However, that list of tables is NOT complete, and will be updated periodically through hotfixes to the Upgrade#.XPO files
    • The same data may be processed more than once because of the shared tables
  • Preparing the data for upgrade
    • Some of these forms will handle virtual companies very well, others will just show repeated data
    • Some forms may require changes to prevent duplicate records being created when the base tables are shared
  • Preprocessing scripts
    • A subset of the preprocessing scripts has been coded to support virtual company scenarios, mostly those for address, dimension and master records
    • Other scripts will require modifications to support data shared in a virtual company to avoid duplicate errors or other conflicts – typically by adding a not exists clause similar to the delta scripts
    • Issues are very likely if the scripts refer to the dataareaid field directly, especially as a join field. You may have to switch the code that directly refers to the dataareaid field to a string that = curext().
    • The same data may be processed more than once because of the shared tables 
  • Delta processing scripts
    • Typically the coding pattern used for delta processing scripts will handle any shared data, but can experience issues if the scripts refer to the dataareaid directly. You may have to switch the code that directly refers to the dataareaid field to a string that = curext().
    • The same data may be processed more than once because of the shared tables
  • Single user processing
    • These scripts generally don’t require any specific changes for shared data
  • Target side processing – Bulk Copy and target post-sync upgrade scripts
    • The bulk copy/mapping functions shouldn’t require any changes for virtual companies. The dataareaid fields are copied directly from the source table to the destination table so they will have the same value throughout this process. There may be a rare case where a unique mapping is added which attempts to join or split tables. That scenario may cause issues if the two tables involved are not both within the same virtual company and table collection.
    • The target side processing scripts do have a possibility for running into unique issues. The table holding the relationship between the virtual company and the table collections (TABLECOLLECTIONLIST) is not automatically copied to the target database with the other system tables during the Connect to source database phase. The reason for this is because the table collections present in AX 2012 are likely different than those in previous versions – e.g. all but two of the built-in table collections present in AX 4.0 and AX 2009 were removed from AX 2012. If a target side processing script attempts to join two tables where one of the tables should be shared as part of a virtual company, the risk exists that no data will be found. To address this issue, users should open the Virtual Company Accounts form using the AOT from a Developer Workspace after connecting to the source database, and adding back the table collections to the appropriate virtual companies. A hotfix will be released in the future to add this as another option on the upgrade checklist.