Forum Discussion
Renaming Field-Parameter issue
I does look like a bug, I agree.
BTW I wasn't trying to imply that a calculated column is "better" (normally it is advisable to avoid calculated columns where possible, so writing the code into the table constructor is probably better). I was suggesting an alternative way to include the columns as per the original poster's needs seeing as changing the column name wasn't working.
I'm with you...but what I don't get is this part:
"We may want to manually enter the values by hand, e.g. create a category for each value that it cannot be deduced by some other column value"
In my second example, I indeed entered values "by hand". Unless you need random values by row (for which we have the RAND function for the final numeric value or to use in a SWICTH function) or a constant value (for which you simply make the column value = whatever you need, you are going to have to assign values by row, which is what I have done in the second example:
which is the equivalent of
And to add values by row or group of rows, you are going to need to reference another column
Maybe I'm being obtuse, but I can't see how the creation of a new column doesn't cater for the "manual" option. If there were dozens/hundreds of rows, it could become and issue. But we are talking about a Field Parameter table, in which the number of rows should be pretty limited.
Any chance you provide an example of how we may need to assing row values without referencing another column?
PaulDBrownAh ok, I understand what you mean now. Yes, we can define a formula that does the job, but maybe there are cases where it is more readable to do it directly on the defining power query formula. For some cases (table of field parameters with a few rows) maybe I'd rather see it written like this, instead of having a switch formula. But whether this is a "better way" of course is subjective! In any case, at the end of the day I do believe that there is a bug here worth reporting.
I does look like a bug, I agree.
BTW I wasn't trying to imply that a calculated column is "better" (normally it is advisable to avoid calculated columns where possible, so writing the code into the table constructor is probably better). I was suggesting an alternative way to include the columns as per the original poster's needs seeing as changing the column name wasn't working.
Yes, I understand! That was a working alternative indeed.