Dynamics AX has a data caching framework on the client that can help you greatly reduce the number of times the client goes to the server. In previous releases of Dynamics AX, this cache operated only on primary keys. In Dynamics AX 2009, this cache has been moved and now operates across all the unique keys in a table. Therefore, if a piece of code is accessing data from the client, the code should use a unique key if possible. Also, you need to ensure that all keys that are unique are marked as such in the Application Object Tree (AOT). You can use the Best Practices tool to ensure that all your tables have a primary key. Properly setting the CacheLookup property is a prerequisite for using the cache on the client. Table 12-1 shows the values that CacheLookup can have. Definitions such as below:
CacheLookup (Found,NotInTTS,FoundAndEmpty,EntireTable,None)
Cache Setting(bold red) Description(blue)
Found
If a table is accessed by a primary key or a unique index, the value is cached for the duration of the session or until the record is updated. If another AOS updates this record, all AOS will flush their cache. This cache setting is appropriate for master data.
NotInTTS
Same as Found except every time a transaction is started, the cache is flushed and the query goes to the database. This cache setting is appropriate for transactional tables.
FoundAndEmpty
Same as Found except if the query fails to find a record, the absence of the record is stored. This cache setting is appropriate for region specific master data or master data that isn’t always present.
EntireTable
The entire table is cached in memory on the AOS, and the client treats this cache as “Found.” This cache setting is appropriate for tables with a known number of limited records, such as parameter tables.
None
No caching occurs. This setting is appropriate in only a few cases, such as when optimistic concurrency control has to be disabled.
When caching is set, the client stores up to 100 records per table, and the AOS stores up to 2000 records per table. Index caching works only if the where clause has column names that are unique. In other words, caching won’t work if a join is present, if the query is a cross-company query, or if any range operations are in the query. Therefore, if you’re checking whether a query record that has a particular primary key and some other attribute exists, search the database only by primary key. For an example of this, refer to xDataArea.isVirtualCompany.