MicroStrategy: Report Caching vs History List
Joaquin Attanasio

Joaquin Attanasio

Business Intelligence Consultant | Microstrategy Expert | Data Specialist

Other Articles:

MicroStrategy Report Caching vs History List

Share on linkedin
Share on facebook
Share on twitter
Share on whatsapp

Talking a bit about optimization techniques, today I come to talk a bit about two very similar functionalities within the tool. Basic for any user, and it is still worth highlighting their importance, similarities, differences, and also their risks, since they jeopardize the veracity of the information displayed. Today, face to face and head to head, I bring you the first fight of the season: Caches vs History list.


Perhaps many have heard of either, both, or neither, but the number of users I see re-running the same reports over and over again, many complaining about the delays involved, is far greater than they realize: Caches vs History list. And while we’re on the subject, let’s introduce the opponents…

History List

You may have noticed that, in the home of each project, by default, we have (in addition to shared reports, my reports, etc) a directory called “History List”.

History List

This is a repository of pre-executed reports and documents. What do I mean by that? It’s simple. MicroStrategy gives us the option to send an object to the “history list” instead of waiting for it to finish.

History List Image

When a report is sent to the history list, it continues to run in the background and is stored in the history. So when we want to check the result, we can go to the folder, and there we will find the report already executed.

This type of action is vital when running reports that take a long time to execute,where there is a risk that there is a connection timeout and what is being executed is lost. When we send a report or a document to the history, it will continue to run until it is finished regardless of whether we log off, log out or continue working with other reports.

The important thing to understand here is that when you send a report to the history, it is as if you were taking a picture of it totally independent of the rest of the objects. That is, if they run a document and send it to history, they can then take the document and modify it, delete it or change the information it displays. But when they go to the history, the version they will find is exactly the one that existed when they clicked on it in the first place.

And this is why each history message (that’s how each object we send is called) has its date and time. If you send the same report or document to history twice, instead of being overwritten, two different records will be created (it is possible to define a limit of records per the report, but we are talking generically).

History List Microstrategy Tutorial


If we go to the straightforward definition, “A cache is a set of results that are stored in a system to improve response time on future requests.”

Microstrategy has different types of cache, but at this time we will focus only on the report cache, and in the future, I will go into detail on how the different types of cache work in the tool.

With caching, users can retrieve results stored in files on the Intelligence Server instead of re-running queries against a database. This means that when you run a report that has a cache associated with it, instead of running the report and waiting for it to finish, the information comes out almost instantly.

The cache is created when the report is run for the first time. Here, the report takes as long as it takes to generate, but it generates a cache, so the next time it is run instead of querying against the warehouse, the stored result will be displayed directly.

Report Caching Microstrategy

The truth is that, for a report to store caches, it must be enabled. At the project level, a default behavior can be defined, but it can also be defined at the report level.

Report Caching MicroStrategy

What do you have in common?

As you can imagine, both methods help us to optimize the performance and response time of the reports that a user runs. Their ultimate purpose is to improve the response time of a query in subsequent requests.

If we go to a more technical level, history is closely related to caching functionality. If you think about it, history is made up of messages that point to report results, and these are stored as “history caches”. Therefore, when a message is deleted from the History list, the History cache to which the message points is also deleted.

Returning to what applies to functionality, both can be generated at the time of execution as well as planned.

Report Caching Update

For example, if I wanted a report (let’s say it takes 2 hours to finish) to run automatically at 6 am to have the data from the previous day, it is scheduled at that time so that when I get to the office at 8 am the report is ready and in a matter of seconds I can already be running it within the tool, so we can use display filters or create documents and graphics based on that report without having to wait for it to run every time… sounds interesting, doesn’t it?

And in the same way, both can be assigned validity. In other words, there may be a period of validity in which they can be used.

What is the difference?

This is where the important part of the issue comes in. There are several points to consider that differentiate one from the other.

  • AccessibilityWhen a cache is created, it is used by all users running the report. For example, if John runs report “A” and then I run it, I will be able to take advantage of the cache that was generated in the first execution. In contrast, history messages are personal and will only be accessible by those users who execute them.
  • Management and maintenance: As I mentioned earlier, there are different types of caches. There are many options to manage and administer the use of caches, while the history is a bit more limited in this regard. Anyway, following on from the previous line, this makes sense as caches are much more global.
  • Versatility: A cache can be reused in documents, reports, users, etc. If a report has any filters, different caches are generated for each of the filters (actually, for each variation of the SQL, so variations also apply at the security level). If we switch from one filter to the other, since both options are cached, the performance will remain optimal, while the history list will re-execute the report.
  • Administration: While the history is personal to each user, the caches are managed by the platform administrators.
  • Validity: If a report, indicator, filter, attribute, or any other object related to a report is modified, the cache automatically becomes invalid.

When is it convenient to use each one?

As you can imagine, there are different scenarios, and depending on each one it is convenient (or possible) to use each one.

In general, conditions, if a report is used massively, perhaps enabling caches is ideal, while if what you are interested in is to have the photo of the specific moment personally to analyze it later, or to make sure that the report will not be interrupted in any eventuality, then sending it to the history is enough.

The truth is that you have to be very careful with both. As I said before, a cache can be invalidated if something is changed in the objects or Query related to the report, but if the data is updated, there is nothing to indicate it, so they may be visualizing and analyzing old data… and that can have a huge impact in many cases. So you know, watch out!


As I said before, at the end of the day, these are two ways that MicroStrategy provides to optimize the execution of reports. Both are complementary, i.e., it is not that you have to choose between one option and the other, but that each user and each project will choose based on their own needs.

Let me know what you think, did you know about both methods, which one do you use more often, are there any features you didn’t know about that I am missing?

I hope you found it useful! See you next time!


Deja un comentario

Your email address will not be published. Required fields are marked *

Business Data Master Logo

No te pierdas el


Explicaremos en detalle los contenidos y objetivos del Business Data Master


18:30 (GTM+1)



* Tu información será utilizada exclusivamente para contactarte en relación al Business Data Master. No hacemos spam ni compartimos datos con terceros.