Record View Caching

Use record view caching to cache the records from a select statement (a result
set). Result set caching is made available through the RecordViewCache class.
The cache is instantiated using a select with the nofetch option. If the
instantiating select is a join, a temporary table or is instantiated without thenofetch option, the cache is not instantiated and an error is reported. The selectclause of the select defines the result set and only "==" predicates are accepted.
The following example illustrates the instantiating of a record view cache:

1 2 3 4 5

SalesLine salesLine; RecordViewCache salesLineCache; select noFetch salesLine where salesLine.SalesId =="100"; salesLineCache = new recordViewCache(salesLine);

The cache is not shared between Microsoft Dynamics AX clients, and is
deactivated as soon as the cache object goes out of scope or is destroyed.
The cache is used when a select is from the same table, not a join and at least
matches the where clause that the cache was instantiated with.
If the table is not set up for Optimistic concurrency then using the forupdate
option on the select within TTS results in database locks on all the rows that are
put into the cache. A subsequent select forupdate within the same TTS is
selected from the cache and not from the database as the row is already locked.
Updates and deletes that match the instantiating where clause simultaneously
maintain the database and the cache. Updates and deletes are not in the above
category do not affect the result-set.
The reread method retrieves data from the database and updates the copy data.
The cache can be instantiated using a select without a where clause. This
effectively creates a copy of the table in memory and functions like a personal
table copy.
The cache is useful for caching tables that are not of static nature, or that contain
so many records that the other caching methods would be impractical.
Because of concurrency issues, the forupdate keyword on the instantiating X++select should only be used when all the records in the result set will be updated.
Otherwise, it is a better strategy to select forupdate the records that are updated
or use Optimistic concurrency on the tables.
Do not use field-lists unless you are certain that the omitted fields will never be
used. There is no warning or error when selecting fields from the cache that were
not included in the select that instantiated the result set.
Inserts normally do not affect the cache even when the record would match thewhere clause defining the result-set.
When you use this form of caching, consider the memory consumption, as there
is no internal limitation to the memory allocated for a single table. Different
application behavior, with regard to exploiting caching when it is running on
server versus client, could be an option.

One example of using record view caching is the class InventMovement. This
holds information about inventory transactions related to one SalesLine,
PurchLine and more. The cache is defined as a RecordViewCache object in
\Classes\InventMovement\classDeclaration.
The cache is initialized by the method
\Data\Dictionary\Tables\InventTrans\Methods\viewCacheInventTransOrigin

1 2 3 4 5 6 7 8 9 10

public static RecordViewCache viewCacheInventTransOrigin(InventTransOriginId _inventTransOriginId, boolean _forupdate = false) { InventTrans inventTrans; inventTrans.selectForUpdate(_forupdate); select nofetch inventTrans where inventTrans.InventTransOrigin == _inventTransOriginId; return new RecordViewCache(inventTrans); }

According to the cross reference, this method is called from
\Classes\InventMovement\viewCacheInventTransId.

1 2 3 4 5 6 7 8 9 10

void viewCacheInventTransOrigin() { if (viewCacheInventTrans) return; viewCacheInventTrans = null; viewCacheInventTrans = InventTrans::viewCacheInventTransOrigin(this.InventTransOri ginId(),true); }

Best Regards,
Hossein Karimi