Using field names as labels

[#1]

Hi - I have field names that are too long and they have the format of db-name.table-name.column-name. By default, Listbox uses the entire field names as Labels. I would like to exclude the prefix and just use table-name.column-name in my case.  Is there a way to manipulate the field names to remove the prefix?  Thanks for any help!

[stigchel]

You can rename the fields at the end of your load script using a mapping. yhis will aslo not change your data model. From the help

Using the Rename Fields Statement

This is a very good method if you want to rename all or some fields at the end of the script run. The best way is to use a mapping table with the old and new field names and use this as follows.

Example:

FieldNameMap;

Mapping Load OldFieldName, NewFieldName From FieldNames ;

Rename Fields using FieldNameMap;

You can store the mapping table in your database or in an Excel sheet so that it is easier to maintain.

[rajkumarb]

Hi Greg

Renaming fields

There are two main reasons for a developer to rename a field:

• To ensure that two tables are associated through the correct fields when

originally these two tables did not share a field with the same name, but

a link does in fact exist between them.

• To prevent unwanted associations between tables when they share a field

with the same name but that field does not actually represent the link

between them.

To rename a field, we can simply use the as keyword in the Load script to assign an

alias to the original field name. For example, take the following Load script, in which

we hypothetically load the Airport descriptions:

[Table_Name]:

LOAD

Code as [New_Field_Name],

Description as [New_Field_Name]

FROM

QlikView 11 for Developers

HTH

[#4]

Thanks, but  can this be done in the UI instead of the load script?  We have developers working on scripts and the designers working on the UI. I have the designer role.

[rajkumarb]

HI Greg

In List box

General-un select - use as Title

IN Caption Select show Caption

Entre your New Field Name there

[#6]

Thank you Raj, but my question is,

     I have field names that are too long and they have the format of db-name.table-name.column-name. By default, Listbox uses the entire field names as Labels. I would like to exclude the prefix and just use table-name.column-name in my case.  Is there a way to manipulate the field names to remove the prefix?

[rajkumarb]

HI Greg

There is another option (in script or in chart)

Right(field, len(field) - index(field, '['))

[stigchel]

No, I would ask the developers who work on the script. Otherwise you will have to manually set each listbox title by typing in the text where it says use field name

[#9]

Thanks. I'm actually looking for something like that, but instead of spelling out the field name, is there a variable or system variable that represents the name of the field.  For example, if the field name is 'abc.xyz' and I just want 'xyz',  does a variable vfieldname exist that allows me to do something like this -

Right(vfieldname, len(vfieldname) - index(vfieldname,'.'))?

[Peter_Cammaert]

You mean a variable that contains the name of the current object? Not as a standard feature. But I could be mistaken, beause there really is an undocumented QV function that gets you the current sheet.

I you are persistent in this, you can look into writing a macro that gets the field name of the listbox. (Don't forget to enable the use of macro functions in QV expressions in hidden options) However, I'm not sure how to get a reference to the current object...

As a side note: you're clearly running into one of the reasons why - somewhere along the different stages of the dataflow - it's a good idea to start thinking in QlikView concepts instead of dragging along those database names. Usually this level of abstraction is introduced in the QDS-phase. For you, the big advantage of this approach would be that at the same same this layer can target the end-user and name all tables and fields in a consise and consistent way. Which is not always the case in source data. Imagine that in the future you want to present self-service BI to your end-users. Should they learn the structure of your RDBMS by heart? 

Best,

Peter