COGNOiSe.com - The IBM Cognos Community

IBM Cognos 10 Platform => Cognos 10 BI => Report Studio => Topic started by: ccbarbeau on 15 Mar 2016 09:28:54 AM

Title: Joining queries based on different data sources
Post by: ccbarbeau on 15 Mar 2016 09:28:54 AM
Good morning,

I am running into an issue that I think is common but I have not found a way to work around it. Here goes; I am on RS 10.1.1.

First query is based on an Oracle DB. Returns tabular data within seconds.
Second query is based on DB2 DB. Returns tabular data within seconds. Contains query item that is in a separate SQL table; query works fine if run alone.

I am joining them to do a simple speed to volume calculation (ie, time estimated to complete a certain task). No matter how I link them, how I cast the linked fields, the join query runs forever until it times out.

Any ideas on how to make this work?
Thanks!
Title: Re: Joining queries based on different data sources
Post by: Kiran P on 15 Mar 2016 02:09:02 PM
What happens when you simply pull a query item from each of these and run the query without creating any calculations?

- Kiran


Sent from my iPhone using Tapatalk
Title: Re: Joining queries based on different data sources
Post by: ccbarbeau on 15 Mar 2016 02:49:00 PM
A join works, as does a union.
Title: Re: Joining queries based on different data sources
Post by: the6campbells on 24 Mar 2016 06:22:27 PM
You are performing a distributed join. In 10.2.2 with Dynamic Query, a feature was provided known as a filter-join. Hence, if you were to join A to B, the engine could scan A first and dynamically generate a predicate on the query for B to select those rows in B with associated key values from A. In the release you are using, A and B are processed as independent queries and joined within the query engine locally.
Title: Re: Joining queries based on different data sources
Post by: the6campbells on 24 Mar 2016 06:31:08 PM
A report studio report can use the Master-Detail layout, at runtime this is akin to a nested-loop operation. That is, if A is populating the master data container, then for each row of A, the detail query for B is executed where you can pass values from A which become predicate values for B. This pattern is also an implicit left outer join (i.e rows from A are still rendered even if there is no B row). If your business query does not require a relational join semantically then this may be a faster solution.

Keep in mind, if there are 1000 rows in A then that translates to 1000 queries to B. Should you move to using 10.2.2+ with Dynamic Query, you will see that master-detail optimization can is available to reduce the # of queries on B. This optimization also applied to other "implicit" master-detail layout patterns such as Page-Sets.

Details in the latest information center and redbook
https://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/sg248121.html?Open