oracle union in qlikview

[#1]

Hi all,

I would like to solve the following problem - to me it's a problem anyway.

1. I have three datasources that I load data from - source_one, source_two & source_three.

2. The query I use fetches the same number & types of fields.

3. Normally I would use a union to organise the data underneath oneanother.

Does Qlikview have functionality to do this?

( in Oracle I would do

source_one

union (all)

source_two

union (all)

source_three

this is the result I would like to accomplish using Qlikview )

Thanks in advance

[tanelry]

Concatenate load

(See QV help for examples... )

[#3]

It turns out that QV does an automatic concatenate if the number of fields - and datatype(?) - are identical.

[#4]

Rob,

Yes.

QV is analysing the fieldnames and it produces a data model out of it, that is cool, but can turn very nasty if ou use QV on a poor data model.

Because QV is producing a combination out of all prossibilities e.g.:

Table Rows - Table Fields

100.000 - 10

100.000 - 10

100.000 - 10

is

100.000*10 * 100.000 * 10 * 100.000 * 10 -> giant number, because it is a combinatoric approach it is not even linear...

You can produce billions of combinations out of tiny data, and bring down QV during load and slowing down the UI as well...a full package of fun

Further depending on the data, you can get circles, QV is detecting them but I am not very sure what they really mean for the data navigation behaviour, so I do avoid them.

For Union All, Qlik View has a problem understanding them. They do work in SQL Developer but they do not work in QV.

But chained/concatened load should be used really carefully and with hindsight, it is practical feature but should not replace a proper data model.

If you use it for just patching together some data to get it done or to avoid data modelling (star scheme) --> that is a bad idea because maintaing QV apps is becoming painful and the behaviour of QV is becoming indeterministic.

Regards,

Stephan

[#5]

Rob,

Yes.

QV is analysing the fieldnames and it produces a data model out of it, that is cool, but can turn very nasty if ou use QV on a poor data model.

Because QV is producing a combination out of all prossibilities e.g.:

Table Rows - Table Fields

100.000 - 10

100.000 - 10

100.000 - 10

is

100.000*10 * 100.000 * 10 * 100.000 * 10 -> giant number, because it is a combinatoric approach it is not even linear...

You can produce billions of combinations out of tiny data, and bring down QV during load and slowing down the UI as well...a full package of fun

Further depending on the data, you can get circles, QV is detecting them but I am not very sure what they really mean for the data navigation behaviour, so I do avoid them.

For Union All, Qlik View has a problem understanding them. They do work in SQL Developer but they do not work in QV.

But chained/concatened load should be used really carefully and with hindsight, it is practical feature but should not replace a proper data model.

If you use it for just patching together some data to get it done or to avoid data modelling (star scheme) --> that is a bad idea because maintaing QV apps is becoming painful and the behaviour of QV is becoming indeterministic.

Regards,

Stephan

[#6]

Rob,

Yes.

QV is analysing the fieldnames and it produces a data model out of it, that is cool, but can turn very nasty if ou use QV on a poor data model.

Because QV is producing a combination out of all prossibilities e.g.:

Table Rows - Table Fields

100.000 - 10

100.000 - 10

100.000 - 10

is

100.000*10 * 100.000 * 10 * 100.000 * 10 -> giant number, because it is a combinatoric approach it is not even linear...

You can produce billions of combinations out of tiny data, and bring down QV during load and slowing down the UI as well...a full package of fun

Further depending on the data, you can get circles, QV is detecting them but I am not very sure what they really mean for the data navigation behaviour, so I do avoid them.

For Union All, Qlik View has a problem understanding them. They do work in SQL Developer but they do not work in QV.

But chained/concatened load should be used really carefully and with hindsight, it is practical feature but should not replace a proper data model.

If you use it for just patching together some data to get it done or to avoid data modelling (star scheme) --> that is a bad idea because maintaing QV apps is becoming painful and the behaviour of QV is becoming indeterministic.

Regards,

Stephan

[#7]

Rob,

Yes.

QV is analysing the fieldnames and it produces a data model out of it, that is cool, but can turn very nasty if ou use QV on a poor data model.

Because QV is producing a combination out of all prossibilities e.g.:

Table Rows - Table Fields

100.000 - 10

100.000 - 10

100.000 - 10

is

100.000*10 * 100.000 * 10 * 100.000 * 10 -> giant number, because it is a combinatoric approach it is not even linear...

You can produce billions of combinations out of tiny data, and bring down QV during load and slowing down the UI as well...a full package of fun

Further depending on the data, you can get circles, QV is detecting them but I am not very sure what they really mean for the data navigation behaviour, so I do avoid them.

For Union All, Qlik View has a problem understanding them. They do work in SQL Developer but they do not work in QV.

But chained/concatened load should be used really carefully and with hindsight, it is practical feature but should not replace a proper data model.

If you use it for just patching together some data to get it done or to avoid data modelling (star scheme) --> that is a bad idea because maintaing QV apps is becoming painful and the behaviour of QV is becoming indeterministic.

Regards,

Stephan