Renaming fields in "Current Selections"

[#1]

Dear QV community members,

Some fields in the script have non friendly names that we can change in the objects with labels.

But when selecting them their original field names names appear in the "Current Selections" box.

Is there a way to make rename these field names also in the "Current Selections" box without renaming them in the script?

Thank you in advance

[Miguel_Angel_Baeyens]

Hi Tony,

I agree and understand how heavy is to rename all fields in the application to fit the users' needs. That's why I suggested a text object, that only shows information (as a text object it does not allow to interact as the Current Selections object does, to clear a field, and all the options that appear in the contextual menu when right clicking on a field name or the object itself). Rather it's a informative list of fields and values, more descriptive for those users that are not familiar with the data source.

Anyway, you can get that functionality, if needed, in a different sheet with some buttons with actions that allow users to select fields and clear them, and at the same time, show the current state of selections in a more say "readable" way.

I'll upload a file if I have time later on today with a very simple example.

Miguel

[#3]

Hi Miguel,

Thank you for the followup. 

I'll wait your suggested sheet.

Tony

[#4]

Will "alias" not achieve the same result as the text object? Alias seems to be much easier to code than actually renaming, too.

[Miguel_Angel_Baeyens]

Hi,

Alias actually renames the field as you did using AS, but in a different part of the script that the AS. Using alias you can only have one name for the field, instead of two, that is what Tony is asking for (one field in the script, the other to visualize data). If you store a field that you have aliased, the name stored will be the AS and not the original, and that's what Tony wants to avoid, because that will mean to recode all the script (at least the extraction and renaming part).

Regards.

Miguel

[Oleg_Troyansky]

Of course we all understand that the right thing to do is to clean up the data structure and not to look for "band-aid" solutions in the UI, right?

The best way would be cleaning up the original QV document. Second best is to clean up the derived document (they you are not dependent on the agendas of others). Simply add a series of "RENAME FIELD" after you load your data from the original document.

cheers,

Oleg

[#7]

Oleg, isn't that what 'alias' would accomplish? (From experimenting with it) It appears you can load the data in the script and then apply the aliases in a seperate portion of the script. These aliases then apply to all fields with that name. The only thing that is not accomplished is having different names in the relational model and the the actual app. It does not allow for two names. I am still unclear whether the goal is to maintain the original names. It seems to me the goal here is to avoid having to dramatically recode the load script, which "alias" seems to accomplish.

[Oleg_Troyansky]

Not quite...

ALIAS needs to be used before loading the data. Alias names will apply to all the following logic. In that sense, if the data is loaded from a source document using "BINARY" load, ALIAS becomes useless.

RENAME FIELD, on the other hand, can be used after the data is loaded. The end result will be the same - certain fields will get renamed, but the timing of the renaming is different.

In the cases where there is a concern about touching a complex load script, RENAME FIELD can be used as the least intrusive:

1. Option 1:

...

LOAD

...

LOAD

...

LOAD

...

<any complex logic goes here>

//==============================

// Rename necessary fields

Rename field XAZ0007 to Sales;

// or renaming using a field map:

FieldMap:

Mapping select oldnames, newnames from datadictionary.;

Rename fields using FieldMap;

2. Option 2 - when the data is loaded from a BINARY load:

BINARY mydata.qvw

//===================

// rename any fields here:

Rename field XAZ0007 to Sales;

...

[Miguel_Angel_Baeyens]

Hi there,

I find particularly useful letting the user know the state that the document has in any given moment, preventing users to getting lost on selections, particulartly when (until) they are not familiar with QlikView, associative logic, selections document wise and so.

I don't see the need for doing anything in the script, even when doing a binary load or renaming fields if the fields available to the users to make selections are a few. At the end of the day you are creating a new document, that requires its appropriate permissions, tasks, licenses assignment and so on.

Definitely I didn't make myself clear enough on this point and I think it's worth going deeper into it.

Obviously, if you want to rename more than a dozen fields (not to mention all of them), using a text box is not the best idea at all. Even renaming is not a good idea unless perhaps it has been developed by outsourced people that is no longer involved in the document or they charge too much for doing some changes or the script is protected and cannot be accessed. As far as I'm concerned I do all renaming in the first step of the script, when extracting data from the source (LOAD SourceField AS IntededName), maybe because I think on the users since the very beginning (and requirements are clear enough, of course).

The complexity of the logic is still there when renaming fields no matter how you do that, that does not save time (not more than the AS would save if done at the proper time), and RENAME does not work with key fields, so far. So why doing in two steps what should have been done in one?

So back to the question: what's the point here? Renaming the fields? No simple way of doing that? Do a binary load using a mapping table based on any flexible source (an excel file will do) with all existing fields and the desired new name. That will affect tasks and performance and licenses but everything has its price, and changing again will not even depend on developers rather than users with access to that flexible source (read excel file).

However if the point is no more than guiding users letting them know why are they seeing the figures they are seeing, and if the Current Selection object shows field names difficult to understand for users (I'm thinking here on SAP-5-letter field names such as "KUNNR" or "WADAT") a simple text object is less intrusive and will perform just fine.

Hope it makes more sense now and sorry the confusion I may have caused.

Miguel

[barryharmsen]

For all the "just do it in the script" people, I just want to add one use case where this does not work: multilingual applications. Unfortunately, in these cases the only option is to use a textbox, such as Miguel describes.

[psankepalli]

Everyone,

It's very foolish to ask same question after 3 years of time.

Does anyone has solution for this requirement? I am facing the same challenge, how do I rename current selection field? I cannot make any change to that filed at script level.

please help!

Thanks

KR