Dynamics Ax Virtual Company & Table Collections

This article describes how Dynamics Ax Virtual Company and Table Collection work. We will also discuss how to move data from normal company to virtual company when you introduce virtual company in existing Ax implementation.

Virtual Company:
Dynamics Ax stores data as per company in tables. But there might be occasions when you want to share data across companies, like country, state, zip codes data. This sharing of data is achieved by creating a virtual company and storing data in this virtual company. Normal companies are then configured to read/write data from this virtual company. The only purpose of virtual company is to share data across companies, you cannot log into this virtual company.

Before seeing how to do virtual company setup, I would like you to show another trick that can be used to share data across Ax. There is a property on Ax tables called “SaveDataPerCompany“, you can use this property to save data globally in Ax. To share data set this property to “No“.

Note: This data is shared by all the companies in Ax. This option will delete DataAreaId field and default (DataAreaId, RecId) index from the table. If you want more control on shared data, like which companies can share and which can not then use virtual company. 

Virtual Company setup:

Step 1: Create Table Collection

Decide which tables you want to share and create a table collection for these functionally related tables. For example; if you want to share Global Address Book across companies then you can utilize the existing table collection “DirPartyCollection”.

To create a table collection, go to AOTData DictionaryTable Collections and on right click select “New Table Collection“, then just drag your required tables in this collection.

Step 2: Create Virtual Company, configure/attach normal companies and table collection

Create a virtual company that will hold the shared data for normal companies.
Note: Before doing the below steps, make sure you are the Ax administrator and the only user online.
  1. Go to Administration — Setup — Virtual company accounts, and create a virtual company.
  2. Decide which companies needs to share data and attach those normal companies with this virtual company.
  3. Attach the table collection with this virtual company.

Your Ax client will re-start and you are done with setting up the virtual company account.

Now, when you have virtual company in place, all new data will be saved in this virtual company. Only companies attached to the virtual company can use this shared data. All other companies which are not attached will work normally, these companies will continue to read/write data as per company bases.

How to move existing data to virtual company?
When you setup a new virtual company, Ax does not move data automatically from normal company to virtual company. This is done by system administrator manually.

There are many ways to do this data move, but I will discuss only two approaches here.

Ax Import / Export:
This is standard Ax approach.

  1. Manually export existing normal company data from Ax.
  2. Remove duplicate records from this exported data set. 
  3. Delete exported data from normal companies.
  4. Import the exported data back in Ax, while logged into one of the participating companies. 
  5. Create records deleted in point 2 again in Ax using your logic. How you want to handle duplicate? For example, if you have customer ‘Rah’ in more than one normal company, what you want to do with this?

Direct SQL:
Use this approach if you have good knowledge about SQL queries and Ax table structures/relationships. Below are few points that will help you understand what to do and how to do.

  • All Ax tables store data as per company unless otherwise specified. For this, Ax uses a special field called DataAreaId. In case of virtual company, it does not matter from which normal company you log-in, it is always the virtual company id which is stored in DataAreaId field of shared tables. 
  • Ax also assigns a unique 64bit number to each record in table. For this, Ax uses a special field called RecId. This RecId is unique in the table and is generated by Ax when you insert a new record in Ax. It is not related to DataAreaId / Company.
  • For unique records between all participating normal companies, update the DataAreaId to the virtual company id.
  • For duplicate records, create them again in Ax using some Ax job or Ax import/export technique.

Attached below are some SQL queries that might help you moving the Global Address Book records from normal companies to the virtual company by changing the DataAreaId.

If you liked the story and want to see more of this kind of content, please follow our twitter handle @CursorRun or FB page @CursorRun
If you liked the story and want to see more of this kind of content, please follow our twitter handle @CursorRun or FB page @CursorRun
Default image
Rahul Sharma
Rahul is a technology enthusiast, solutions architect, trainer, and blogger, working on various Microsoft and open source solutions with more than 18 years of industry experience. He specially takes interest in designing enterprise applications, cloud integrations, IoT, and other architecture rich business solutions. Rahul is a guest author with us and shares his knowledge through technology blog posts.
Articles: 59


Enter your email address below to subscribe to our website. We will never flood your inbox with unwanted emails & you can always unsubscribe anytime.


  1. Hrm, can't see the attached sql queries mentioned. Get a msg in that area: "This webpage is not available."

  2. Please make sure your firewall is not stopping it..

    Direct link for this file is http://cid-0e75794c17db3f50.skydrive.live.com/self.aspx/blog.rahulsharma.in/SQLQuery-GlobalAddBook-Move-Blog.sql

Leave a Reply

%d bloggers like this: