Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
scotthan
Partner - Contributor III
Partner - Contributor III

Two QVWs, one set of objects??

Community, I have an extremely large application, both in terms of data and number of objects. The goal is to divide this into two applications. The first (new) app will show only today's data. The second (existing) app will still show today's data plus the three year history. We have already taken steps to limit the history.

The new app showing only today's data will be exactly the same as the old app, except that it won't include 50% of the objects which are all historical trends.

For all of the objects that are common to both applications, the question is: Is it possible to have two applications referencing the same objects, such that if we make a change to an object in the first app it will be reflected in the second app and vice versa?

I have taken an initial stab at this copying objects between -prj folders. I've run into some problems, such as if the QlikviewProject.xml file references xml files (objects) that don't exist, it throws an error.

All thoughts appreciated, thank you.

Scott

2 Replies
Not applicable

Hi Scott,

Because all you appreciate all thoughts, i got 1 for you!

It seems to me you want to split your QVW because of performance issues?

Why not solve the performance issues first?

Do you use allot of set analysis or similar aggregations? This in combination with allot of data and objects will have allot of impact on the performance.

I would suggest you put some or all calculations in your load script in the model. This way, you limit the calculation time at userside.

There are enough other options to try later.

You can upload the qvw if you need some help with bringing the calculations to the back-end.

I'll hope you give this a try first!

Kind regards,

Jelco

scotthan
Partner - Contributor III
Partner - Contributor III
Author

Hi Jelco, thanks for your advice. I have been throught the standard performance improvements on the application. There are certain hardware limitations that slow this one down that we won't be able to get around though, hence the split.

Looking for a potentially creative solution to share work between two Qlik documents.