Does the RENAME command apply to all tables?

[datanibbler]

Hi,

one question rgd. the RENAME FIELD command: Does that, like the DROP FIELD command, apply to all tables unless some tablename is specified? If yes, how do I do so? I want to rename one field, but only in the one table I just loaded.

´Thanks a lot!

Best regards,

DataNibbler

[Or]

If you have the same field name in two tables, QlikView will treat it as the same field (which is why you shouldn't count() on it, for example, and Show Frequency is disabled for it as a key).

If you're using QUALIFY, you can use the fully-qualified name:

QUALIFY *;

Table1:

LOAD * INLINE [

    C1, C2

    A, 1

    B, 2

];

Table2:

LOAD * INLINE [

    C1, C3

    A, 3

    B, 4

];

Rename Field Table1.C1 to Table1.C4;

[tresB]

It just renames those which are already loaded. Therefore, you may rename a loaded field before another gets loaded.

[Kushal_Chawda · Accepted solution]

This depends on where you have written the RENAME statement.

For eg. If you have written the RENAME statement after loading all the tables, it will perform renaming of the field in all the table.If you have written the RENAME statement after particular LOAD then it will perform renaming for that particular load (Table).

By the way if you just want to rename the field in one table then you can simply rename it using 'as' alias

[swuehl]

For questions likes this, I suggest looking into the HELP pages:

Rename field ‒ QlikView

The RENAME statement does not allow a ...FROM TABLENAME like the DROP statement.

So it applies to all tables where the field is part of (because it changes only the meta data of that single symbol table).

[datanibbler]

Hi kushal,

this is where I was actually "aiming" my question: So QlikView does rename that field in every table already loaded where the fieldname is the same and I Need to use a QUALIFY Statement to avoid it.

That's too bad. I had an alias, but just for that one field. That made the LOAD unoptimized and I thought I could make it optimized by RENAMing the field lateron - but if I have to qualify the table to do that, I will Need an alias for every field in a RESIDENT - the fields have to be concatenated to an existing table. I'm afraid that won't make things better 😉

Thanks a lot!

[swuehl]

Datanibbler,

a simple alias of the field should not un-optimize the QVD LOAD.

Are you sure that's the only transformation you are doing?

[datanibbler]

Thanks swuehl,

the Thing is, there are some Little Details and tricks which are not in the HELP file, for example the possibility of passing a Parameter of "-1" to the FINDONEOF function. That's why I asked.

Best regards,

DataNibbler

[datanibbler]

Hi swuehl,

yes, I'm quite sure that

a) there is no other Transformation being done in this step AND

b) that the LOAD, such as it was, was not optimized (it would be in the Debugging_window if it was)

It is strange, yes - currently, that LOAD fetches only 22k records, so it's not really worthwhile, but it might grow, I cannot tell because I don't yet know where that qvd is coming from.

The LOAD is/was like this:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Concatenate (Fehlerdaten)

LOAD Fehlercode,
Type,
BUKR as %Stamm_BUKR,
Fehlercount,
Timestamp
FROM
$(vQVDPfadLesen)QS_Stammdaten_Fehler.qvd
(qvd);

I have no idea - this time there was no preceding LOAD.  Can you think of another possible reason?

The strange Thing is: I changed this aroundn - first making it a separate LOAD and then concatenating in a RESIDENT - and I dropped the RENAME Statement again and it still resulted in an optimized LOAD 😉

[swuehl]

Does the resident table 'Fehlerdaten' you are concatenating to show the same number and names of fields (i.e. Fehlercode, Type, %Stamm_BUKR, Fehlercount, Timestamp)?

If not, then I believe you are losing the optimized LOAD not because of the alias, but due to concatenation with different structure.