Qlik Community

Ask a Question

QlikView App Dev

Discussion Board for collaboration related to QlikView App Development.

Announcements
Our next Qlik Insider session will cover new key capabilities. Join us August 11th REGISTER TODAY
cancel
Showing results for 
Search instead for 
Did you mean: 
niktherussian
Contributor
Contributor

Intraday & Historic Reporting

Good morning guys & girls,

 

I've been tasked with a new project for our business whereby we have a new system in place which they would like reported both live (intraday reporting - would look at live data from last 2 days) & aggregated/historic data [looking at MOM/YOY etc].

Has anyone created a dashboard which features this kind of functionality? Would it be possible to create parts that have to be reloaded every 15 mins from SQL (for the intraday/live reporting), whilst the historic data can run/reloaded off stored down data in QVDs (which are updated overnight for instance)?

Currently the thought process is to create 2 dashboards for the requests - one for historic and one for intraday, however in my minds eye creating one big dashboard may be more efficient (not definitely - this is just an idea currently). It's simply whether there's a way of facilitating what I've stated above. (very obscure I appreciate).

If anyone has any input please let me know. Alternatively if there are any questions that I can answer I will - please remember this project is business sensitive thus I cannot give much information surrounding it. 

 

Cheers ears!

1 Solution

Accepted Solutions
edwin
Specialist III
Specialist III

what confuses me is why section access is a factor here.  why would different users have different rights to same data but different dates.

regardless you do have both options that will work:
single dashboard data divided by dates and section access enabled. 
2 dashboards, different dates, different reload times, and different sets of users

i suggest that the 2nd option would be more efficient both in reload times, no section access required, and simpler to maintain both in script and in QMC 

View solution in original post

4 Replies
edwin
Specialist III
Specialist III

if historical is huge,you may not want to reload that every 15 mins.  

you can binary load historical data and reload the incremental into it.  thus you can reload your historical once a day and your 2nd stage every 15 mins after that.

edwin
Specialist III
Specialist III

i just realized that depending on your architecture, you may not want to have two datamodels.  in which case, an alternative is to save the historical tables in QVDs and consume the QVDs in your DM that runs every 15 mins.  you create the QVDs only once a day.

niktherussian
Contributor
Contributor
Author

Hi Edwin,

That seems logical to me. The historical data would be stored down in QVDs which would refresh overnight. Meanwhile the in-day data would be pulling direct from SQL, at the end of each day this data would ideally store down into the QVD to be encompassed within the historical data. The historical data would have a max range of up to 25/26 rolling months.
What I'm thinking currently is one big dashboard for the historic data with section access for those who would need to see the in-day reporting. The in-day reporting is the priority so will be building around that first and then building the historical extracts etc.

If I stagger this approach (i.e at a lower level create the historical reporting) & then binary load the historical, followed by the live/in-day load from SQL - does this (in your minds eye) sound like it should work?

edwin
Specialist III
Specialist III

what confuses me is why section access is a factor here.  why would different users have different rights to same data but different dates.

regardless you do have both options that will work:
single dashboard data divided by dates and section access enabled. 
2 dashboards, different dates, different reload times, and different sets of users

i suggest that the 2nd option would be more efficient both in reload times, no section access required, and simpler to maintain both in script and in QMC 

View solution in original post