Qlik Community

QlikView App Development

Discussion Board for collaboration related to QlikView App Development.

Announcements
QlikWorld, June 24-25, 2020. Free virtual event for DI and DA gurus. Register Today
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Creator
Creator

Duplicated field values problem

I have a model that has some customers who can be using several services that sit in one or more reporting sectors. My problem is this qvw gives the same total fee in each sector category and not the actual fees per sector.

I have looked at the Table Viewer, the column names in the various tables and the synthetic keys. I have tried to remove the synthetic keys but ended up making it worse.

Has anyone out there seen this problem and have advice or a solution I can try?

7 Replies
Highlighted
Not applicable

Duplicated field values problem

Can you maybe attach the qvw or a sample of the code that is creating problems so we can better assist you?

Highlighted
Creator
Creator

Re: Duplicated field values problem

Attached is a word doc with the code, an object example of the problem and

the table viewer. I appreciate any help as I have only recently started

workng with Qlikview. Can you tell me why this prolem has occurred?

On Mon, Mar 19, 2012 at 6:07 PM, bapperson <

Highlighted
Luminary
Luminary

Duplicated field values problem

Those  synth keys are there becuase you are joining the tables by more than 1 key. If you want to avoid them you need to join the tables only using 1 key.

Highlighted
Not applicable

Duplicated field values problem

I will try to change this to my best guess of what you are shooting for. 

It seems that Heirarchy Name is something you actually want to join the tables on, so we will leave that alone.  See the changes below.

Directory;

LOAD

[Hierarchy Name],

[Week No],

Date,

[Pay Cycle],

[Target Payslips],

[Target Net Fee],

[Base Client]

FROM

(ooxml, embedded labels, table is Sheet1);

Directory;

LOAD Date,

[Financial Year],

Quarter,

[Accounting Month],

[Accounting / Payroll Week] as [Accounting / Payroll Week cal],

WeekDay,

[Year Ref] as [Year Ref cal],

Month,

MonthYear,

Day

FROM

(ooxml, embedded labels, table is calender);

Directory;

LOAD [Client Name],

[New Client Name],

[Hierarchy Name],

Sector,

[Reporting Sector],

[Account Manager]

FROM

(ooxml, embedded labels, table is [ClientHierarchy]);

Directory;

LOAD [Hierarchy Name],

Date as [Date Sheet2],

[Pay Cycle] as [Pay Cycle Sheet2],

[Gross Fees],

[Total Rebate],

[Net Fee],

[Actual Payslips],

[Year Ref] as [Year Ref Sheet2],

[Accounting / Payroll Week] as [Accounting / Payroll Week Sheet2],

[2011],

[2012]

FROM

(ooxml, embedded labels, table is Sheet2);

As I am unsure what you are actually trying to join the tables on this is just a guess, but it will remove synthetic keys (I hope).  The basic idea is that you should make sure anything you do not wish the tables to be joined on should be renamed. 

So when you see $Syn3 and below it you see:

Date

Accounti...

year Ref

Heirarch

Pay Cycle

Then you need to rename most of those fields to make sure that they are not the same in both tables.

Unless of course you are intending to join the tables on multiple keys.

Hope this clears things up a bit!

Highlighted
Creator
Creator

Re: Duplicated field values problem

Thanks alot for the helpful reply. I had tried to rename fields once before

but that seemed seemed to lose interconnectedness from those fields. I also

thought to use autonumbers as a way of creating the equivalent of ID number

specific fields to reduce multiple occurences of names in the tables.

Should I try Joins after renaming these fields and if so what type would

you suggest? An example would be great.

On Tue, Mar 20, 2012 at 5:27 PM, bapperson <

Highlighted
Not applicable

Duplicated field values problem

You should leave the field names the same if the data occurring in both places is the same.  For example if the Date and Heirarchy Name coming from sheet2 is the same date and Heirarchy Name coming from Sheet1 then you should no alias them.

One somewhat easy way to join the tables without having to worry about which type of join is just to name different tables in your script.  QlikView will then link things automatically.

For example you could do:

Sheet1:

LOAD

[Hierarchy Name],

[Week No],

Date,

[Pay Cycle],

[Target Payslips],

[Target Net Fee],

[Base Client]

FROM

(ooxml, embedded labels, table is Sheet1);

Calender:

LOAD Date,

[Financial Year],

Quarter,

[Accounting Month],

[Accounting / Payroll Week],

WeekDay,

[Year Ref],

Month,

MonthYear,

Day

FROM

(ooxml, embedded labels, table is calender);

etc...

This will find the common field of Date between the two tables and link them automatically.


Otherwise If you have a main table where you know there is always an entry I would start with that and if you have other tables where there might not always be a match use a left join as it will do everything in the first table that is in the second.  Or if you already know there is a matching record for everything in every table use inner join to find exact matches between tables.

An example would be:

Table1:

ID

1

2

3

4

Table2:

ID, num

3, 100

4, 200

If you did Table1 Left Join Table2 you would get:

ID, num

1, -

2, -

3, 100

4, 200

- is null or blank

Whereas Table1 inner join Table2 would get:

ID, num

3, 100

4, 100

Highlighted
Creator
Creator

Re: Duplicated field values problem

Many thanks for the join examples, they make sense. I will try and

experiment with them.

I understand that with Date and Hierarchy Name in sheet 2 and sheet 1

they can be left alone so Qlikview automatically links them. The fact

they are also in Target meant a synth key was created so I will work

on that.

Interestingly the other synth keys were created although there were

only two occurrences of the same name in two different fields. I

believe Qlikview created the synth keys because it's logic said there

was a loop. Something I failed to see when I was designing the table

layout and still is not so obvious to me. This gives me something to

think about.

Once again thanks for your help, much appreciated.