BLOGS BY TOPIC
BLOGS BY AUTHOR
BLOGS BY YEAR
Posted by Sam Lowrie on 30 July 2018
You need a minimum screen resolution of about 700 pixels width to see our blogs. This is because they contain diagrams and tables which would not be viewable easily on a mobile phone or small laptop. Please use a larger tablet, notebook or desktop computer, or change your screen resolution settings.
Debugging (sort of) in DAX
This is another tip via the DAX wizard Marco Russo, this time about tracking errors in your code. Consider this long winded code to paginate tables:
It'll be a pretty grim job to try and work out what it does. The code is from my blog on creating pagination in tables.
While this formula might look impressive, it is difficult to follow and even harder to find where an error occurred. By a huge coincidence there was one:
Let's face facts: Microsoft error messages aren't always the easiest to decipher, and we haven't made it any easier!
What would make this clearer would be to break the long formula into two or more separate measures. However, dividing a single measure like this into separate ones can change its functionality (not to mention creating clutter!). We need a single-measure solution!
Variables
Enter the DAX variable, which allows us to create a measure within a measure. To create a variable enter VAR followed by a name and an equals sign:
The Return command is used at the end of the measure to return a value. No return, no numbers!
The above isn't going to help much but, it does give the outline for using variables. Now I want to split the code into separate functional parts:
Whilst I might still be getting an error, how much nicer is this to read!
Now for the cool part. Instead of returning the final value, comment it and all other variables out bar the first one. Put the first variable next to the Return:
The error is gone! This means that it isn't caused by any DAX for the first variable. It also lets me check the variable is returning what I expected.
I can now repeat the process, un-commenting the next variable and returning it until I find the error. Turns out it was actually the very last step that was causing the error:
So between my variable PageNumberV and Final_Value there is an error due to the wrong data type.
It's simple enough to fix this with a little FORMAT function:
Instead of making the Final_Value more complex, I snuck in another variable.
There it is, debugging DAX using variables. Whilst it would be nice to have a true debugger like VBA, this is currently what we have, and using variables will improve your code!