I would like to give my fields an alternative 'friendly' name, without changing the actual name of the field in the data model.
I've noted that solutions such as Alias, As, Qualify, Rename etc actually rename the field, but I don't want to do this, since we have hundreds of objects that use the existing field names.
I would just like to be able to change (a) the dimension labels (b) list box titles to show an alternative friendly field names, based on a mapping table of actual field names and friendly field names.
I've thought of a few ideas, but can't make them work:
- link my friendly field names to $Field in the system table
- somehow populate and use $Info in the system table
- load in a table of field name and friendly field name (as island data) and somehow refer to this in the Label box in the object
- do something with GetObjectField
- do something with Tags
Hi Rory, I'm not sure to understand... to set a somewhat dymanic value in chart dimension label you should fix the identifier of the text, ie, having a field-label table:
LOAD * Inline [
Label for Field1 can be:
If one [Field] is selected, using just [Label] will return the label
You can create one variable for each field's label. It can easily be populated from a table or a spreadsheet:
vLabelField1 = 'Actual Sales';
Then in a label you could have this Expression:
A creation of these variables could be like this:
LOAD * INLINE [
Field1, Actual Sales
FOR i=0 TO NoOfRows('LABELS')-1
vFieldName = Peek('FieldName',i,'LABELS');
vFriendlyName = Peek('FriendlyName',i,'LABELS');
[vLabel$(vFieldName)] = '$(vFriendlyName)';
i=; vFieldName=; vFriendlyName=;
DROP TABLE LABELS;
Hi thanks for your quick reply, your idea works partially, but if I have a table with 5 columns, I would need to write a different expression in the Label box for each dimension. That would be the same as manually renaming the dimensions. Is there some way to use a common expression that would work for all dimensions?
Yes, the advantage is that you can maintain labels outside, so one change in FieldLabelTable switches the label in all objects using that label.
Label text boxes are not related with any data, I'm not sure if there can be a way using macros.
i think that the only way you can get that is to create a friend variable for each field.
Then in the object you put the name of the variable in the label like Petter suggestion.
Fields name in the script are involved in many processes (joins for example) ...
maybe renaming your fields might turn out to cause less effort than creating alias tables and adding label expressions to all of your objects after all.
Another downside would be that you will always confuse your users by presenting different field names in the current selections box than is shown in your dimension labels (as the former will always show actual field names).
Yes you will have to specify a different label for each.
Alternatively you could export/store your QVW as XML and then use a script to keep the labels in sync with a table of friendly names:
The QlikView documentation says this about "Project Files":
I clipped this from a blog post by Rob Wunderlich @rwunderlich (you can find it here: https://qlikviewcookbook.com/2017/11/mass-editing-of-qvw-script/ ) :
QlikView Desktop has a useful facility we can leverage for mass changes; the “-prj” folder. If a folder named qvwname-prj (case sensitive) exists in the same folder as the QVW, when the QVW is saved, QV Desktop will write a set of text files representing the structure of the QVW to the -prj folder. One of those files is “LoadScript.txt” which contains the load script.
When QV Desktop opens a file, it checks for the existence of a companion -prj. If found, it populates the QVW with the contents of the files in the -prj. If we change one of those files, for example “LoadScript.txt”, that change will be inherited by the QVW.
So if you are brave you can make some kind of script that reads the relevant XML-files and modify the relevant labels according to which field that they are associatied with. It is quite simple and straightforward programming but if you're not familiar with programming it might be a daunting task.
I think you are just paying the price for not considering user-friendly fieldnames in beforehand. Of course you could change with more or less efforts the labels of all your fields (Ruben and Petter hinted to various ways of doing it) but I agree with Marco that a proper renaming will be in general the easiest way of handling rather cryptic fieldnames. With a mapping-approach you could apply the renaming directly within your reporting-layer (maybe after a binary load) and keeping the origin fieldnames throughout all your development-layers.