App Crashes When Trying to Define and Expand Specific Measures about daxstudio

[marcosqlbi]

Can you provide the code of the underlying measure(s) ?

[dgosbell]

@marcosqlbi I think I can see the issue. The way [Days to Transfer] used in the calculate makes it look like a measure reference, but then there is also a reference to it inside the values function in the filter where it would also have to be a column reference.

So I think we have that new potential issue we identified with the PowerBI where it's possible to have a column in one table that has the same name as a measure in another table. Then the "expand" feature is incorrectly trying to expand both the measure and the column reference leading to an infinite loop where it eventually overflows the string buffer.

So I think we need to check if the character immediately proceeding the [Days to Transfer] string is NOT one of the following:

• an alphanumeric character
• a single quote

To ensure that we only expand measure references and not column references.

I have a test PBIX file where I was able to reproduce this issue and code a fix

[marcosqlbi]

In reality you might have a column reference without the table name (e.g. in a SUMX or FILTER function), so this could be not enough. However, I see the problem in being too much restrictive here. Probably the best would be:

1. Check whether the character immediately proceeding the measure is not an alphanumeric character or a single quote
2. If condition 1) happens, evaluate whether the measure has the same name of a column in the data model.
3. If condition 2) is true, then show a warning to the user asking whether he wants to go ahead with the replace or not. If the user cancel, don't do anything
4. If condition 2) is false or condition 1) is false, do the replace

What do you think about this approach?

[dgosbell]

Yes, I think you are right. The current change I've made will expand out local column references incorrectly as if they were measure references. I'll need to see if I can refine it further along the lines you've suggested. But from my testing it appears that the Tabular engine will resolve the "short" form of a name to a column from the current table if one exists, otherwise it will resolve to the measure, so I think we should maybe do the same.

[marcosqlbi]

Yes, but the problem is that understanding what is the "current" table is very complex, we should parse the DAX syntax. You can solve the problem easily just in a calculated column, but what if you have:
SUMX ( Categories, SUMX ( RELATEDTABLE ( Products ), [Price] ) )
Then Price could be, in this order:

• a column in Products
• a column in Categories
• a Measure

I think that using measures and columns with the same name should be forbidden (and it is in Power Pivot and SSAS Tabular UI). Thus, if an author wants to go against the best practices, well, we will provide no support for measure expansion... :)

Let me know if I should take a look to the code, too.

[DaveStabilify]

Forgive me for not responding sooner - I did not see the first few comments.

The measure [Days to Transfer] is simply AVERAGE( Investigations[Days to Transfer] ). However, Investigations[Days to Transfer] is a calculated column that provides the days between two other date column values in Investigations (1M row fact table).

But this is where it gets messy because the resulting DATEDIFF of the two date columns can produce a negative result. So the DATEDIFF has to be wrapped in a SWITCH statement in order to accommodate both positive and negative scenarios.

This leads me to the next question - should I create an intermediary table that simply contains the calculated columns (there are more than one) from the fact table?

Thanks for your help.

[marcosqlbi]

SQLBI site is working - what is the page you are trying to access?
Please write to [email protected] if you need assistance for that, thanks!