topic Re: Qualify Vs No Qualify in QlikView

Qualify Vs No Qualify

Fri, 22 Nov 2013 14:51:50 GMT

I'm Qualifying names and loading 2 tables, but QV doesn't automatically join them because the names are qualified.

I was thinking in not Qualifying them, but then I realized I cannot do it because fields in other tables with names like the ones I'm loading will be joined automatically.

So I think I should keep Qualifying fields to keep everything separated, but then how will I join tables?

Thanks,

Miguel

Re: Qualify Vs No Qualify

dirk_konings — Fri, 22 Nov 2013 14:54:24 GMT

You use 'Qualify * ;' for qualifying every field created behind this statement.

use 'UnQualify KeyField1, KeyField2 ;' so these 2 fields won't be qualified.

See Help for examples.

Dirk

Re: Qualify Vs No Qualify

datanibbler — Fri, 22 Nov 2013 14:56:40 GMT

Hi Miguel,

well, that is (generally) a bit of a problem because of QlikView's "associative logic" that will automatically join tables with equal field_names.

A long-term solution to this might be using link_tables (essentially the same as the synthetic_keys you would get with several equal-named fields, only in "goodie")

<=> As a short-term solution, use two commands:

- QUALIFY *

- UNQUALIFY (enter here the fields you want to join on, see help_file for details).

Be careful about this, however, especially when you have incremental LOADs around - it's usually safer to undo all of those things as soon as you don't need them anymore.

(or, instead of UNQUALIFY, you could just load those particular fields with an alias_name)

HTH

Best regards,

DataNibbler

Re: Qualify Vs No Qualify

Fri, 22 Nov 2013 14:57:24 GMT

Thanks, but that doesn't look like an elegant solution.

What if the not qualified fields are elsewhere in the Script?

Re: Qualify Vs No Qualify

Fri, 22 Nov 2013 14:59:59 GMT

The JOIN are made automatically by QV with the names. And only the names.

If you want tables to be joined, you MUST have common names. One field in common is best to avoid the synthetic keys.

Fabrice

Re: Qualify Vs No Qualify

Fri, 22 Nov 2013 15:01:08 GMT

Synthetic keys are not allowed in our system by our administrators and I can't change that policy.

Unqualifying the key fields doesn't look elegant for me.

About the alias you suggested it also doesn't work because QV joins fields by their original name and not by their alias.

Re: Qualify Vs No Qualify

Fri, 22 Nov 2013 15:02:18 GMT

Since it seems the only solution possible provided by everyone, it looks like I will have to Unqualify que key fields.

But it doesn't look elegant...

Re: Qualify Vs No Qualify

Fri, 22 Nov 2013 15:05:02 GMT

I don't know why we cannot disable QV associative logic with a keyword like:

ASSDISABLE *;

for example

or why can't I join specifying fields with different names, like in SQL....

Re: Qualify Vs No Qualify

datanibbler — Fri, 22 Nov 2013 15:06:20 GMT

Hi Miguel,

synthetic keys are forbidden by your admins? That's funny 😉 They are not good, technically speaking, in a qvw, but I don't see how that would be relevant to your admins - well, you can avoid them by using linking_tables.

You can avoid the UNQUALIFY by using a RESIDENT LOAD and placing the alias there - it works, I've done it before, like this:

JOIN ([table_#1])

LOAD

....

.... as [field_name as in table_#1]

RESIDENT [table_#2]

;

Re: Qualify Vs No Qualify

Anonymous — Fri, 22 Nov 2013 15:17:29 GMT

Miquel

You could rename the qualified fields you wish to link using :

Rename Field QualifiedField to LinkFieldName ;

And leave the rest qualified as you wish.

Also you could have a look at this blog Circular References by HIC.

It mentions, in passing, “loosely coupled” tables which are disabled from the QV associative logic

I have never done this and am not sure I wold want to, but it is an interesting read.

Best Regards, Bill

Re: Qualify Vs No Qualify

Josh_Good — Fri, 22 Nov 2013 15:22:04 GMT

QlikView approached data modeling from a user first approach. Typical users don't understand or care about data modeling they just want to see and navigate through data. Therefore anything in the data model that has the same name is considered samething (just like the real world). Best practice is to make all of your fields business friendly names at the time of load.

Re: Qualify Vs No Qualify

whiteline — Fri, 22 Nov 2013 20:57:30 GMT

ASSDISABLE *;

Really funny

Agree, at first your fields should be business friendly.

Then you could use additional key files with a proper logic to link your data, almost like the real world. Sometimes you can even hide them from users.

Qualify is not about data modeling, it's just a useful tool for developers to separate fields more easily.