Valid Time State Key Error after Upgrading or Updating
Hello AX World,
Have you ever had a compilation error “Table does not contain a valid time state key. A unique index needs to be marked as a valid time state key.” and could not realize where it came from? I had… many times and I did not have a clue until one day.
Such errors look strange as they show up on completely standard objects.
I have noticed that they were showing up after upgrades or updates (CUs, hot fixes etc.). That gave me a hint. I know that during an upgrade there are upgrade scripts running to enable or disable certain indexes. So I assumed that these scripts are not behaving well enough. I tried to dig it up, to find scripts that were failing and I have found the problem.
Cause
The the index is disabled using indexAllowDup method, then properties AlternateKey and ValidTimeStateKey are reset to default value No.
ReleaseUpdateDB::indexAllowDup(new DictIndex(tableNum(TableName),
indexNum(TableName, DateEffectiveIndex)));
The error starts to show up then indexes are not enabled correctly using method indexAllowNoDup:
ReleaseUpdateDB::indexAllowNoDup(new DictIndex(tableNum(TableName),
indexNum(TableName, DateEffectiveIndex)));
AlternateKey and ValidTimeStateKey properties are not set using the code and then you start getting compilation error mentioned above.
Solution
You should use the method indexAllowNoDupAndDateEffective instead:
ReleaseUpdateDB::indexAllowNoDupAndDateEffective(new DictIndex(tableNum(TableName),
indexNum(TableName, DateEffectiveIndex)), ValidTimeStateMode::Gap or NoGap);
Sometimes you can see the following code, but that is implemented in indexAllowNoDupAndDateEffective method:
DictIndex dictIndex = newDictIndex(tableNum(TableName),
indexNum(TableName, DateEffectiveIndex));
dictIndex.modify(true, false, true);
dictIndex.setAlternateKey(true, true);
dictIndex.setValidTimeStateKey(true, ValidTimeStateMode::Gap or NoGap, true);
appl.dbSynchronize(dictIndex.tableid(), false);
Recent experience
I have got 3 errors after upgrading from AX 2009 to AX 2012 R3. In earlier versions I had experienced even more…
Tables that there failing:
- EximDBKValues_IN (Index: TariffCodeIdx)
- EximDEPBScheduleTable_IN (Index: ProductGroupTableRecIdx)
- PdsRebateAgreement (Index: SeqIdx)
- ReleaseUpdateDB60_Cust. allowDupEximDBKValues_IN
- ReleaseUpdateDB60_Cust. allowNoDupEximDBKValues_IN
- ReleaseUpdateDB60_Ledger.allowDupEximDBKValues_INTariffCodeIdx
- ReleaseUpdateDB60_Ledger.allowNoDupEximDBKValues_INTariffCodeIdx
EximDEPBScheduleTable_IN table had 2 methods as expected but index enabling was incorrect.
- ReleaseUpdateDB60_Ledger.allowDupEximDEPBScheduleTable_INProductG
- ReleaseUpdateDB60_Ledger.allowNoDupEximDEPBScheduleTable_INProduc
public voidallowNoDupEximDEPBScheduleTable_INProduc()
{
ReleaseUpdateDB::indexAllowNoDup(newDictIndex(tableNum(EximDEPBScheduleTable_IN),
indexNum(EximDEPBScheduleTable_IN, ProductGroupTableRecIdx)));
}
PdsRebateAgreementtable had 2 methods, the same as EximDEPBScheduleTable_INand enabling index was incorrect.
- PmfReleaseUpdateDB60_Pds.allowDupPdsRebateAgreementSeqIdx
- PmfReleaseUpdateDB60_Pds.allowNoDupPdsRebateAgreementSeqIdx
public voidallowNoDupPdsRebateAgreementSeqIdx()
{
ReleaseUpdateDB::indexAllowNoDup(newDictIndex(tableNum(PdsRebateAgreement),
indexNum(PdsRebateAgreement, PdsRebateAgreementSeqIdx)));
}
I hope that helps you to save some valuable time to spend on more interesting things.
Respectfully,
Evaldas
This was originally posted here.
*This post is locked for comments