Hi everyone!
Time for another tricky question!
I've seen some BPs around the Net encouraging NotInTTS CacheLookup option for tables in Transaction table group. So I went along and created a simple table like this:
![]()
With the following properties:
![]()
I compiled and sync'ed the table of course.
The next step was to create a couple simple jobs to make the table worthwhile: one to insert a single record into a table and another to retrieve data from it.
So the first job looks like this (nothing fancy):
static void TestInsertNotInTTS(Args _args)
{
TestNotInTTS d;
;
d.SourceTableId = 359;
d.SourceRecId = 5637197918;
d.InstanceId = 65;
d.MyVersion = 3;
ttsBegin;
d.insert();
ttsCommit;
info(strFmt("RecId = %1", d.RecId));
}The second one is no fancier than the first. It does 2 selects - one by the business key (the four fields) and another select goes by the record id key returned by the previous job:
static void TestSelectNotInTTS(Args _args)
{
TestNotInTTS d;
;
// select by business keys (copied query from PCRuntimeConfigurator::PER_InitProductAttributeDetailLines())
while select d
where d.SourceTableId == 359 &&
d.SourceRecId == 5637197918 &&
d.InstanceId == 65 &&
d.MyVersion == 3
{
info(strFmt("SourceTableId=%1, SourceRecId=%2, InstanceId=%3, MyVersion=%4, RecId=%5, WasCached=%6",
d.SourceTableId, d.SourceRecId, d.InstanceId, d.MyVersion, d.RecId, d.wasCached()));
}
// select the same by primary key which shows in SQL database
d.clear();
select firstOnly d where d.RecId == 5637144580;
info(strFmt("SourceTableId=%1, SourceRecId=%2, InstanceId=%3, MyVersion=%4, RecId=%5, WasCached=%6",
d.SourceTableId, d.SourceRecId, d.InstanceId, d.MyVersion, d.RecId, d.wasCached()));
}So I run the first job, note down the returned RecId, then quickly turn to another job, hand-type the RecId in the where clause of the second select statement and run it.
Surprisingly I get some inconsistent results from both select statements, most notably that for the server-side cache record the RecId shows incorrect:
![]()
A straight SQL query from SSMS returns proper RecId:
![]()
Furthermore, should I repeatedly run my second job for a little while (a minute or so), the RecId eventually catches up:
![]()
Is this behavior expected, especially the RecId being out of whack for some time?
Running Dynamics AX 2012 CU8 to be accurate.
Will appreciate any ideas.
