Skip to main content
Announcements
Qlik Connect 2024! Seize endless possibilities! LEARN MORE
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

History Table or QVD

Hi,

We have a table which updates in every 15 min and wont saves any history. I want to create a report which shows history data. Now my question is do I need to create a new table which stores history data in the database ? Or Can we maintain history in QV side by creating QVD or any other option? If yes how? (I want to update my history data first or last hour not for every 15 min )

Thanks In Advance.

1 Solution

Accepted Solutions
johnw
Champion III
Champion III

Without knowing specifics, here is my general recommendation for cases like this:

  • Maintain history in a new, separate history database. When you add, change, or delete a record, write history. The history record should look like the regular record, but with at least a timestamp attached. Additional information may be desirable. The timestamp should be indexed.
  • Keep a history QVD separate from the live QVD.
  • Use an incremental load when building the history QVD. The timestamp index will allow you to do this efficiently.

Why I wouldn't do it in QlikView:

  • A series of snapshots of a database is NOT a full history of that database. It might be sufficient for now, but may not be in the long run.
  • A QlikView history is useless to you if a program in your source system needs history at some point. Don't build it twice. Build it once, in the source system.
  • QlikView is a reporting system, not a data-processing system. History seems to me more of a data-processing requirement.
  • QlikView can have accuracy issues, such as with the storage of fractions.

View solution in original post

2 Replies
johnw
Champion III
Champion III

Without knowing specifics, here is my general recommendation for cases like this:

  • Maintain history in a new, separate history database. When you add, change, or delete a record, write history. The history record should look like the regular record, but with at least a timestamp attached. Additional information may be desirable. The timestamp should be indexed.
  • Keep a history QVD separate from the live QVD.
  • Use an incremental load when building the history QVD. The timestamp index will allow you to do this efficiently.

Why I wouldn't do it in QlikView:

  • A series of snapshots of a database is NOT a full history of that database. It might be sufficient for now, but may not be in the long run.
  • A QlikView history is useless to you if a program in your source system needs history at some point. Don't build it twice. Build it once, in the source system.
  • QlikView is a reporting system, not a data-processing system. History seems to me more of a data-processing requirement.
  • QlikView can have accuracy issues, such as with the storage of fractions.
Not applicable
Author

Thanks John