2012 R3 Dimension Framework Stack Trace and Debug Assert

While posting a general journal, I received the following stack trace on a Debug::assert() in class DimensionAttributeValueGroupValidation method doGetStatusFromStatusRecord().

[s] \Classes\DimensionAttributeValueGroupValidation\doGetStatusFromStatusRecord 57
[s] \Classes\DimensionAttributeValueGroupValidation\getStatusForRequest 17
[s] \Classes\DimensionAttributeValueGroupValidation\getStatus 29
[s] \Classes\DimensionValidation\getStatusForCombination 27
[s] \Classes\DimensionValidation\getStatusForRequest 29
[s] \Classes\DimensionValidation\getStatus 25
[s] \Classes\LedgerVoucherTransObject\check 140
[s] \Classes\LedgerVoucherTransObject\checkData 37
[s] \Classes\LedgerVoucher\addTrans 15
[s] \Classes\LedgerJournalTransUpdate\ledgerVoucherCheck 118
[s] \Classes\LedgerJournalCheckPost\checkJournal 412
[s] \Classes\LedgerJournalCheckPost\run 144
[c] \Classes\LedgerJournalCheck\main 49
[c] \Classes\FormFunctionButtonControl\Clicked
[c] \Forms\LedgerJournalTable\Designs\DesignList\CheckJournal\Methods\Clicked 22

The associated comment in the source code immediately suggests data corruption.  The DimensionAttributeValueGroupStatus record being validated has field IsValid set false (0), but none of the other fields (InvalidValueConstraintNotFound, InvalidValueIsSuspended, or InvalidValueIsTotal) have been set true (1) to indicate why the record is not valid.  According to the comment, such a record should never have been written.



Some quick SQL reveals that the issue is probably not limited to just the one record at hand.  Out of 22,843 records in the DimensionAttributeValueGroupStatus table, 47 records apparently share the same underlying problem.



Presuming for now that the IsValid is correctly false, the question is which of the Invalid fields should justify that status.

I started by joining the suspicious DimensionAttributeValueGroupStatus records back to DimensionAttributeValueCombination records to get a feel for what Main accounts and account structures were involved.



Conveniently, some of these are quite simple with only Main accounts and no additional dimension values.  For those records, I can tell immediately that they're not suspended, so InvalidValueIsSuspended of false seems correct.  It's also immediately obvious that they're not total account (they do exist, but these are not among them), so InvalidValueIsTotal of false also seems correct.

At this point that I discovered that these particular Main accounts have an account structure that requires the Business unit dimension and blank is not allowed, so now I know that IsValid of false is correct rather than just presuming it, but InvalidValueConstaintNotFound should be true in that case.

To test that theory, I selected another Main account sharing the account structure that requires Business unit, but for which no DimensionAttributeValueCombination or DimensionAttributeValueGroupStatus record yet exists.  In other words, I found a Main account that had never been used anywhere in the system without a Business unit, and attempted to use it for the first time in a General journal.

As expected, the validation code set InvalidValueConstraintNotFound to true in code.



An error was generated in the UX.



SQL confirms that the DimensionAttributeValueGroupStatus record was created with InvalidValueConstraintNotFound set true.



It's difficult to draw a firm conclusion from this investigation as to the root cause, but it I'm certain at this point that I have some DimensionAttributeValueGroupStatus records that should have InvalidValueConstraintNotFound set to true to justify IsValid set to false, and confidence that they are legitimately not valid for use and an understanding of why that is the case.

Perhaps this data corruption is left over from an earlier version of AX.  Since most of the Dimension framework records are not enabled for CreatedDateTime or ModifiedDateTime system fields, there is not enough information in the data to confirm such a suspicion.  Just based on RecId's alone, assuming that RecId's only increase over time, some of these records seem pretty recent and that's a concern for another day.