After Reload - Field Names Show with Boxes to Assign to Current Names

[nhaataja]

Hi!

We are building a back end data gain template application for use in a front end template.  There are two excel files which will be loaded each time - the Master List & the TPA File.  Using variables that the user inputs in the back end before clicking reload, we are loading them into their respective tables like this:

NOCONCATENATE
TPA_DATA:
LOAD *
FROM
[$(vFilePath)\$(vTPAFileName)]
(ooxml, embedded labels, table is $(vTPATab));

NOCONCATENATE
MASTER_LIST:
LOAD *
FROM
[$(vFilePath)\$(vMasterListFileName)]
(ooxml, embedded labels, table is $(vMasterTab));

Our excel source files will each have varying column names but we would need them to be renamed into the generic column names that will be used in the front end.  Something like this:  FirstName / FST_NM / FRST_NM depending on source file.

Here is our ask:  Is there a way to program a box to appear after reload that will list columns imported per file and allow the user to assign them to the generic column names so that they can be associated in that way?  Can that box also allow us to assign each field a #?

We do not want to have to manually rename field names each and every single time.  We also do not want to import data that is outside of our identified generic fields.  We also need this to be usable for personnel who cannot build anything in Qlik so it has to be very easy for the user.  We will never know what column names will be until we hit the reload button so I am hitting quite a wall trying to accomplish this.

Any help would be greatly appreciated.

[Miguel_Angel_Baeyens]

Short out-of-the-box answer: no, it's not possible.

Field names are specified during the script, which means that whatever change wants to be made to the field names or the fields themselves must happen during a reload. Even if you find a solution, another reload must happen so the names chosen by the user are used in the data model.

Also, the data model is unique for the application, if users John and Jane are accessing the same app they will use the same field names, it cannot be e.g.: "Date" for John and "Timestamp" for Jane, it will be whatever was specified in the script.

That said, there could be creative solutions so the data model is loaded as usual, but users can choose how to display them on the screen, (e.g.: changing the title). However this can also be confusing, because if John and Jane are using the same data model, but John's app reads "Monthly sales per month" and Jane's reads "Monthly amount" when referring to the same field, I don't really know whether both values are comparable (and they are).

That means you are not really changing field names but _how you display them_, and that's definitely something any user can do in any object.

Thinking out loud approaches:

1. What they could use is a data model which is common for both, they binary load it into their apps, and you create an extension to visually aid the field renaming. After that, they will reload their apps and those will be two separate, different apps, based on the same source (the data model).
2. So, while in general I don't really like the approach of using different names for the same fields, what about doing it _before_ the _final_ reload, so there is an Excel template where you list on column A the data source names and column B is populated by the users? You use that spreadsheet to rename fields and once they fill that file, they can then reload it and see their own names.

Important to mention, these approaches won't allow you to use section access, for example, and each user will have to create their own. Also, any expression or QVD they create will not be reusable.

[nhaataja]

To clarify - John & Jane would be working with completely different files & we'd want their results to match exactly.  John's file might say FIRST NAME and Jane's file might say FIRST_NAME but we'd want them both to export to QVD as FST_NM.  So I'd want a box to pop up after original load with a list of all field names & drop downs so that they could be associated with our generic field names before a reload to make these changes happen.