Which CacheLookup properties should you use?

DRAG DROP

You are a Dynamics 365 Finance developer.

You need configure table caching.

Which CacheLookup properties should you use? To answer, drag the CacheLookup properties to the correct table. Each property may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view content. NOTE: Each correct selection is worth one point.

View Answer

Answer:

Explanation:

Box 1: FoundAndEmpty

All selects on caching keys are cached, including selects that are not returning data.

All caching key selects are returned from caching if the record exists there, or the record is marked as nonexistent in the cache.

A select forUpdate in a transaction forces reading from the database and replaces the record in the cache. An example of FoundAndEmpty record caching is in the Discount table in the Microsoft Dynamics AX standard application. By default, the Discount table has no records. By using a FoundAndEmpty cache on this table, the keys that are queried for but not found are stored in the cache. Subsequent queries for these same non­existent records can be answered from the cache without a round trip to the database.

Box 2: NotInTTS

All successful caching key selects are cached.

When in a transaction (after ttsBegin), no caches made outside the transaction are used. When inside a transaction, the record is read once from the database and subsequently from the cache. The record is select­locked when reading in a transaction, which ensures that the record cached is not updated while the transaction is active.

A typical example of the NotInTTS property is on the CustTable in the Microsoft Dynamics AX application. It is acceptable to read outdated data from the cache outside a transaction, but when data is used for validation or creating references, it is ensured that the data is real-time.

Box 3: EntireTable

Creates a set-based cache on the server. The entire table is cached as soon as at least one record is selected from the table. An EntireTable cahce is flushed whenever an insert, update or delete is made to the table. So first select read all records from DB for the selected company and all the further selects will take data from the cache instead of DB calls.

Box 4: Found

All successful caching key selects are cached. All caching key selects are returned from the cache if the record exists there. A select forUpdate in a transaction forces reading from the database and replaces the record in the cache. This is typically used for static (lookup) tables, such as Unit, where the record usually exists.