Referencing Master Measures / Fields with identical names
Recently, Qlik added the ability to reference master measures within expressions, which is great. However, if the master measure shares a name with a field in the app, Qlik appears to automatically revert to referencing the master measure rather than the field, with no option to determine which one you meant. Has anyone else encountered this and hopefully figured out a way around it that doesn't involve renaming every field/master item where this is the case (which isn't necessarily a bad idea, but hard to find across hundreds of apps where it may occur)? Anyone know if this is even intentional behavior, as I would have expected the field to have precedence over a master item in this scenario?
If a duplicate name is used in an aggregation function, it is interpreted as a field. Outside of an aggregation function, measure has precedence. There is no option I'm aware of to modify this behavior.
Note the recommendation that you should not use the same name for a Field, Measure or Variable due to the potential for confusion. QSDA Pro flags duplicate names found in an app.
For new apps, I have taken to using the convention of adding a value qualifier to my field names. For example, for "Sales", the Measure is named "Sales" and the field is "Sales Amount". I am doing more renames in my script than I used to. I've become very fond of the Alias statement 🙂
For existing apps I have yet seen anything broken because I'm typically using a field within an aggregation function. I'd be curious to hear if anyone has an example of a broken app because of this new feature.
If a duplicate name is used in an aggregation function, it is interpreted as a field. Outside of an aggregation function, measure has precedence. There is no option I'm aware of to modify this behavior.
Note the recommendation that you should not use the same name for a Field, Measure or Variable due to the potential for confusion. QSDA Pro flags duplicate names found in an app.
For new apps, I have taken to using the convention of adding a value qualifier to my field names. For example, for "Sales", the Measure is named "Sales" and the field is "Sales Amount". I am doing more renames in my script than I used to. I've become very fond of the Alias statement 🙂
For existing apps I have yet seen anything broken because I'm typically using a field within an aggregation function. I'd be curious to hear if anyone has an example of a broken app because of this new feature.
I ran into a case where it broke something today, which is why I popped in to ask. The issue in question is with measure expressions named FieldName along the lines of:
Which is a quick approach to swapping between e.g. metric and imperial units which are kept in different fields, original / translated currency values, and the like. This appears to be picking out the master measure FieldName, perhaps because of the implied Only() in measure expressions that don't have an explicit aggregation. An actual basic example would be a master measure named [Unit Weight]:
If(Selected_Unit_Type = 'Metric',[Unit Weight], [Imperial Unit Weight])
Which results in a circular reference to the master measure [Unit Weight].
Presumably, the fix here is to either rename things so they don't clash and probably also avoid the use of measures to display what is really a dimension value (it's quicker to do it this way and I think the performance is better too compared to a calculated dimension, but it isn't the cleanest approach). Nothing that can't be worked around, for sure, just a mild annoyance to have it break stuff in an unexpected way...
Thanks for the example. It's an excellent example of the ambiguity issue. if you had explicitly used Only([Unit Weight]), it would have used the Field rather than the measure.
Thankfully the syntax checker colors Measures and Fields differently which is useful.
