Create two tables with a parent-child relationship
Hi all
I use Qlikview to generate a number of reports. I have one general template which creates a standard report, and custom templates that contain slight modifications of the standard report. Currently, I created the tables for both the standard and custom template separately. This is an example of what I have:
Table A (standard report):
Dimension
Expression 1
Expression 2
A
10
11
B
20
21
Table B (custom report):
Dimension
Expression 1
Expression 2
Expression 3
A
10
11
65
B
20
21
87
In this example, both tables show exactly the same dimensions and most of the expressions. The only difference is that the second table contains one more expression (which is defined in the standard report table as well, but not enabled).
The issue comes when I need to make structural changes (e.g. adding a field to all report tables): in this example, I would need to manually modify both tables to add a new expression.
Is there a way to link tables in a parent-child relationship? By this I mean having tables A and B such that any changes in table A are automatically applied to table B as well, but changes to table B are not applied to table A.
I explored link objects, but they put both objects on an equal ranking and apply changes to both.
No, that's not possible. You can create variables that contain dimension names or expressions and reuse them in the chart so that changing the content of a variable will be reflected in all the charts where the variable is used. But the scenario you describe is not possible. Well, I suppose you could start mucking about with macro's, but that can get very messy very quickly.
I actually realized a way around this, by using 'conditional' conditions on most custom expressions.
Basically, I can create one table that contains all possible expressions; I then need a field list which tells me whether I am running a standard or custom report. Finally, I can use conditional on all custom expressions in the table based on the values taken on by the field list.
It's not 100% optimal, I would still need to create some additional tables when expressions are substantially different, but it's an improvement.
