Cache Lookup In AX 2012
Single record caching
Found
Found caching will assign for the main table, to find the unique record, like CustTable.
Found and Empty
Similar to Found, when there is empty record can be cache, will be used for Group Tables like custGroup.
NotInTTS
Will be used for Transaction tables like CustTrans, because to avoid to cache the NotInTTS records.
Set-based caching
EntairTable
This will be used mainly for Parameter table as it contains the single record to cache full table data.
Record Caching
Microsoft Dynamics AX database record caching is a performance-enhancing feature that helps avoid database access when it's not strictly necessary. Retrieving database records from memory instead of the database significantly speeds up data access. Caching can reduce the performance penalty for repetitively accessing the same database records.
Types of Caching
Caching is transparent to the application; however, it's important to know how caching works to optimize its performance in Microsoft Dynamics AX. Following are the types of caching:
Single-record
Set-based
Single-record caching has the following characteristics:
Defined at design time
Moves records to the cache based on the table's CacheLookup property and the type of SELECT statement that is used to retrieve the record
For more information about record caching, see Single-record Caching.
Set-based caching has the following characteristics:
Defined either at design time or in X++ code
Moves sets of records to the cache
Implemented either through the table's CacheLookup property or in code by using the RecordViewCache class
Set-based Caching [AX 2012]
EntireTable Cache
When you set a table's CacheLookup property to EntireTable, all the records in the table are placed in the cache after the first select. This type of caching follows the rules of single record caching. This means that the SELECT statement WHERE clause must include equality tests on all fields of the unique index that is defined in the table's PrimaryIndex property.
The EntireTable cache is located on the server and is shared by all connections to the Application Object Server (AOS). If a select is made on the client tier to a table that is EntireTable cached, it first looks in its own cache and then searches the server-side EntireTable cache. An EntireTable cache is created for each table for a given company. If you have two selects on the same table for different companies the entire table is cached twice.
Single-record Caching [AX 2012]
Record caching is enabled for a table when all the following statements are true:
The CacheLookup property on the table is enabled by setting it to one of the following values:
NotInTTS, Found, FoundAndEmpty.
The record buffer disableCache method has not been called with a parameter of true.
Records are cached for all unique indexes when all the following criteria are met:
The table is cached by having its CacheLookup property set to NotInTTS, Found, or FoundAndEmpty.
The select statement that selects the records uses an equal operator (==) on the caching key. The fields in the where clause of the select statement match the fields in any unique index.
Single record caching
Found
Found caching will assign for the main table, to find the unique record, like CustTable.
Found and Empty
Similar to Found, when there is empty record can be cache, will be used for Group Tables like custGroup.
NotInTTS
Will be used for Transaction tables like CustTrans, because to avoid to cache the NotInTTS records.
Set-based caching
EntairTable
This will be used mainly for Parameter table as it contains the single record to cache full table data.
Record Caching
Microsoft Dynamics AX database record caching is a performance-enhancing feature that helps avoid database access when it's not strictly necessary. Retrieving database records from memory instead of the database significantly speeds up data access. Caching can reduce the performance penalty for repetitively accessing the same database records.
Types of Caching
Caching is transparent to the application; however, it's important to know how caching works to optimize its performance in Microsoft Dynamics AX. Following are the types of caching:
Single-record
Set-based
Single-record caching has the following characteristics:
Defined at design time
Moves records to the cache based on the table's CacheLookup property and the type of SELECT statement that is used to retrieve the record
For more information about record caching, see Single-record Caching.
Set-based caching has the following characteristics:
Defined either at design time or in X++ code
Moves sets of records to the cache
Implemented either through the table's CacheLookup property or in code by using the RecordViewCache class
Set-based Caching [AX 2012]
EntireTable Cache
When you set a table's CacheLookup property to EntireTable, all the records in the table are placed in the cache after the first select. This type of caching follows the rules of single record caching. This means that the SELECT statement WHERE clause must include equality tests on all fields of the unique index that is defined in the table's PrimaryIndex property.
The EntireTable cache is located on the server and is shared by all connections to the Application Object Server (AOS). If a select is made on the client tier to a table that is EntireTable cached, it first looks in its own cache and then searches the server-side EntireTable cache. An EntireTable cache is created for each table for a given company. If you have two selects on the same table for different companies the entire table is cached twice.
Single-record Caching [AX 2012]
Record caching is enabled for a table when all the following statements are true:
The CacheLookup property on the table is enabled by setting it to one of the following values:
NotInTTS, Found, FoundAndEmpty.
The record buffer disableCache method has not been called with a parameter of true.
Records are cached for all unique indexes when all the following criteria are met:
The table is cached by having its CacheLookup property set to NotInTTS, Found, or FoundAndEmpty.
The select statement that selects the records uses an equal operator (==) on the caching key. The fields in the where clause of the select statement match the fields in any unique index.
Very Good post! Could you give guide me to improve the site Spa in Colombo
ReplyDelete