web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics AX (Archived) / Debug::assert failing ...
Microsoft Dynamics AX (Archived)

Debug::assert failing on number

(0) ShareShare
ReportReport
Posted on by Eivildas Kaškonas 65

Hello,

Recently I noticed a strange behaviour of Debug::Assert failing on particular number: 225654272000

71573.Untitled.png

Is this number some sort of "magic" or what? Can anyone confirm that in their systems this fails too?

I've tried this number in older Ax (Ax3.0, Ax2009) - it went ok, no error. Seems this fails only in Ax2012.

This assert failed on standard MS check somewhere in Financial dimension validation of attribute RecId.

I'm wondering that there are a lot of more similar checks on RecId and it might fail again on same number somewhere else in whole system.

*This post is locked for comments

I have the same question (0)
  • Community Member Profile Picture
    Community Member on at

    Hi!

    It's magic.

    I tested with same result.

    But argument for function assert has  boolean type and it works correct for correct argument

        int64            test = 225654272000;
    ;
    //good
    Debug::assert(test != 0);
    //bad
    Debug::assert(test);


    Imho 2012 has int64 and can not implicitly correct convert to boolean sometimes

  • Verified answer
    Martin Dráb Profile Picture
    Martin Dráb 237,880 Most Valuable Professional on at

    I think the reason is that first you assign the number to the boolean parameter, which is stored as a byte. What division remainder will you get if you divide 225654272000 by 256 (which is the effect of overflow)? Zero. And zero is interpreted as false.

    You shouldn't ignore types, despite the fact that AX is very benevolent about them.

  • Eivildas KaÅ¡konas Profile Picture
    Eivildas Kaškonas 65 on at

    Well, this might explain then. By the way, this is not my code, but Microsoft (Dimension type check in one of classes). I already applied != 0 in our system.

    Other thing - why if (225654272000) - works? Shouldn't there be same Kernel check on boolean Expression in "if" condition and debug::Assert()?

    Usually I always try to use as much as possible boolean expressions rather than leaving other types to handle for Kernel and decide if that type is True of False.

  • Martin Dráb Profile Picture
    Martin Dráb 237,880 Most Valuable Professional on at

    All right, it's somebody else's bug then. :-)

    "If" statement is a different scenario - there is no assignment to any variable and therefore no overflow. Assert() likely uses if statement as well, but the value it uses is already zero.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)

#1
Martin Dráb Profile Picture

Martin Dráb 4 Most Valuable Professional

#1
Priya_K Profile Picture

Priya_K 4

#3
MyDynamicsNAV Profile Picture

MyDynamicsNAV 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans