MicroStrategy - History List

mstr

Articles
https://community.microstrategy.com/t5/Server/TN44171-What-is-Hybrid-History-List-repository-in-MicroStrategy/ta-p/193950
https://community.microstrategy.com/t5/Server/TN13711-How-to-invalidate-delete-caches-and-History-List/ta-p/174235

DSSCSMSGINFO
DSSCSCONTENT
DSSCSRPTCACH

How can we enable the "send to history list" feature automatically?

  1. Log into MSTR Web as administrator
  2. Click on the appropriate project
  3. Click on Preferences (on the top menu)
  4. Click on Project Defaults (on the left hand side)
  5. Click on History List (on the left hand side)
  6. Click on the radio button next to Automatically (at the top of the page, under the "Add reports and documents to my History List")
  7. Select the appropriate option such as "Apply to all projects …"
  8. Click the Apply button

How can we backup report history cache to database?

  1. Launch Developer / Desktop
  2. Drill down on the right project source
  3. Right click on the right project source and select Configure MicroStrategy Intelligence Server
  4. Click on History Settings -> General (on the left hand side)
  5. Check the check box next to Backup report history caches to database
  6. Click on the OK button

How can we restrict the number of history list messages?

This is a bit confusing to me. It seems that we can restrict the number of messages using the Preferences screen, but in the Project Configuration screen of the Desktop tool, we can also change a number.

  1. Launch Desktop
  2. Drill down on appropriate project source
  3. Right click on appropriate project
  4. Select Project Configuration
  5. Click on History List on the left hand side
  6. Change the Maximum number of message per user
  7. Click OK.

We can also do it in the Configure MicroStrategy Intelligence Server screen:

  1. Launch Desktop
  2. Drill down on appropriate project source
  3. Right click on appropriate project source
  4. Select Configure MicroStrategy Intelligence Server
  5. Expand History settings -> General (on the left)
  6. Change the Maximum number of message per user setting.
  7. Click the OK button.

How can we change the history list replacement policy?

  1. Launch Desktop
  2. Drill down on appropriate project source
  3. Right click on appropriate project source
  4. Select Configure MicroStrategy Intelligence Server
  5. Expand History settings -> General (on the left)
  6. Change the Message lifetime (days) setting.
  7. Click on Replacement Policy (on the left)
  8. Change the Number of messages deleted to reclaim History List space setting
  9. Click the OK button

What is the "CDSSServerMessage::DropResultID(): RptCacheAdmin->ReleaseInboxRefCount return error 0x225 error message" mean?

The occurrence of this error message indicates that the cache to be deleted cannot be found. A History List message retains a reference to a History cache file on the file system. When attempting to delete a History List Message, the cache file associated with that message is deleted if there is no other message pointing to the cache. It may be that the cache directed by the history message to be deleted has already been deleted and can no longer be located. Therefore, the error message appear.

The appearance of this error in the logs is not associated with any malfunctioning of the MicroStrategy Intelligence Server. Administrators should, however, investigate to determine what action caused the deletion of a cache file associated with a History List message before the deletion of the History list message itself.

What does the "Maximum number of caches has been reached. Cannot create new caches." error message means?

A user sends a report to history. Upon opening the History folder (either in 3-tier or 4-tier), the report is displayed in the History List with a status of 'Execution Error'. When the user attempts to view the details of this message the following message appears: Maximum number of caches has been reached. Cannot create new caches. Please contact your administrator.

This issue occurs because the maximum number of caches in the project has been reached. However, since the maximum number of history messages per user has not been reached, the user is still able to send reports to History. The status of the corresponding message is set to 'Execution Error'.

When the MicroStrategy Intelligence Server attempts to write the cache to disk, it fails because the maximum number of caches for this particular project has been reached. Consequently, the following message gets logged in DSSErrors.log:

ReportCacheAdmin::AddInboxRefCount() return error = 0x40041E12 for msg 0050F1C348DC46AC8F4796BBE18C841B

There are two possible solutions for this issue:

  1. Increase the "Maximum number of caches" setting for the project in Project Configuration > Caching > Reports (general). Note: Increasing this setting requires restarting MicroStrategy Intelligence Server.
  2. Delete any unused caches. For more information on how to invalidate or delete caches, refer to the following MicroStrategy Knowledge Base documents:
    1. TN5300-8X-0780 - How to invalidate/delete caches in MicroStrategy Intelligence Server using a scheduled administrative task?
    2. TN5303-8X-2525 - What is the difference between invalidating, expiring, deleting, and purging a report cache in Microstrategy Intelligence Server 8.x?

How can we throw away all the data in the history list database?

  1. Re-initialize the history list using the Configuration Wizard

How can we configure the History List to use a database instead of the filesystem?

See the installation page

How can we manually purge history list?

With the introduction of Database Based History List in MicroStrategy 9.x, History List Messages monitor has also been added to MicroStrategy 9.x.

  1. Launch Desktop / Developer
  2. Connect to appropriate project source
  3. Drill down on Administration -> System Monitors
  4. Right click on the history list monitor, select Filter, specify the filter criteria. You can filter by project name, and by date.
  5. Click on Apply.
  6. Right click on the history list monitor again and select Purge and click on the Purge button

This monitor does not appear when File Based History List is used. This monitor is only visible once the user has configured Database Based History List.

How can we invalidate/delete caches and History List messages in MicroStrategy Intelligence Server using a scheduled administration task?

Cache management can be automated in MicroStrategy Intelligence Server using the administration scheduling in MicroStrategy Desktop. In order to schedule administration tasks, follow the steps below:

  1. Login to MicroStrategy Desktop as an administrator and connect to a 3-tier project source.
  2. Go to the Administration menu and select Scheduling -> Schedule Administration Tasks. The Schedule Administration Tasks window opens.
  3. History List messages can either be deleted for all the projects or for selected projects only. This can be selected from the Available projects drop-down list.
  4. Select 'Delete History List messages' from the actions drop-down list
  5. Select one of the pre-defined schedules. The schedules used for the scheduling of administration tasks are the same schedules used for scheduling of reports and created under the Schedule Manager.

Several administration tasks can be performed using the 'Schedule Administration Tasks' window including invalidating/deleting caches as well as deleting History List messages.

History List messages can be deleted using several different criteria:

  1. Lifetime (days): Users can choose to delete messages that are older than a given number of days since creation. For example, if the number entered here is 10, the system will delete all the messages that are more than 10 days old and keep those that are less than 10 days old. A value of 0, which is the default value, means that all messages will be deleted regardless of their creation time.
  2. Status: Users can also specify the status of the History List messages to be deleted that includes: (Read, Unread, All)
  3. Groups: Users can also specify the user or group by using the Add Members dialog box

How can we purge orphan rows?

To detect orphan rows:

SELECT COUNT(CONTENT_ID) FROM DSSCSCONTENT WHERE SUB_ID = 2048 AND CONTENT_ID NOT IN (SELECT(RESULT_ID) FROM DSSCSMSGINFO);

To purge orphan rows:

DELETE FROM DSSCSCONTENT WHERE SUB_ID = 2048 AND CONTENT_ID NOT IN (SELECT(RESULT_ID) FROM DSSCSMSGINFO);

After upgrading a history list repository from MicroStrategy 9.0.x to MicroStrategy 9.2.x or higher, expired report caches still remain in the DSSCSCONTENT table after they are no longer needed. These report caches cannot be removed after running the Administrative Tasks "Clean History List Database" or "Delete History List Messages."

Causes of orphan rows:

  1. Starting in MicroStrategy 9.2.0, the DSSCSRPTCACH table was introduced as a dedicated table to store report caches only. In previous versions all the MicroStrategy objects related to History list caches management (including report caches) were stored in the DSSCSCONTENT table. During the upgrade of the History List Repository, if the option "Copy History List content" is unchecked, the History List management mechanism will recognize the fact that there are report caches that are contained in the DSSCSCONTENT table and will use the new table DSSCSRPTCACH for all newly created report caches. The History List management mechanism will continue to use the existing report caches in the DSSCSCONTENT table until all of the existing report caches in the DSSCSCONTENT tables are expired. After the report caches used in the DSSCSCONTENT table are expired they will be removed through the Administrative Task "Delete History List Messages." If the history list messages have been manually deleted from the DSSCSMSGINFO table then there will be no association back to the report caches in the DSSCSCONTENT table, therefore they will not be deleted by Administrative Tasks.
  2. There may be other causes

In MicroStrategy Intelligence Server 9.0.2, the scheduled administrative task 'Clean History List database' has been introduced. Below is a list of the operations performed by this task:

  1. Cleans up orphaned rows in the DSSCSCONTENT and DSSCSRPTCACH (new table introduced in MicroStrategy Intelligence Server 9.2.0) table when the Caches for the History List message is deleted first and then History list message itself is deleted from the remote node (cleanup report cache orphan row)
  2. Cleans up History list for those users deleted from Metadata. The old methods of History List deletion (Message Lifetime, Scheduled task) are based on the user being present in the Metadata. It is always possible for a user object to be deleted in 2- tier, without the users History List being cleared, or an administrator may delete a user from the Metadata without remembering to clear the users History List messaged as well. In this scenario, the users History List message will remain on disk and the associated “History” cache will never be deleted.
  3. Cleans up History List for those projects deleted from the metadata.

To manually delete orphan rows:

  1. Go to Administration -> Events. Right click and select New. Give the name Cleanup History List
  2. Go to Administration -> Schedules. Right click and select New. Give the name Cleanup History List and select event-trigger
  3. Go to Administration -> Schedules. Right click and select Schedule Administrative Task
  4. Go to Administration -> Events. Right click on Cleanup History List and select Trigger

The way to ensure there are no orphaned rows in the DSSCSCONTENT table is to create an admin task to delete History List message (not History List caches). Deleting History List messages will trigger deletion of History List caches from file and from the database leaving NO orphan rows. On the other hand, deleting History List caches first (either manually or via an administrative task), will only trigger the deletion of History List caches from the file system and leave unreferenced History List messages on the system. At this point deleting the History List messages will leave orphaned rows in the DSSCSCONTENT table.

What does the administrative task Clean History List Database do in MicroStrategy 9.0.2 and later?

In MicroStrategy Intelligence Server 9.0.2, the scheduled administrative task 'Clean History List database' has been introduced. Below is a list of the operations performed by this task:

  1. Cleans up orphaned rows in the DSSCSCONTENT and DSSCSRPTCACH table table when the Caches for the History List message is deleted first and then History list message itself is deleted from the remote node.
  2. Cleans up History list for those users deleted from Metadata. The old methods of History List deletion (Message Lifetime, Scheduled task) are based on the user being present in the Metadata. It is always possible for a user object to be deleted in 2- tier, without the users History List being cleared, or an administrator may delete a user from the Metadata without remembering to clear the users History List messaged as well. In this scenario, the users History List message will remain on disk and the associated “History” cache will never be deleted.
  3. Cleans up History List for those projects deleted from the metadata.

What are the tables in the history list database?

  1. DSSCSSYSPROP: This table stores a set of system properties used by content services such as current version of History List content service, maximum number of SQLs in a batch, encoding type, maximum length of a string column and maximum length of a BLOB column. These properties are not configurable and should not be changed. Columns:
    1. PROP_NAME
    2. PROP_VAL
  2. DSSCSMSGINFO: This table stores information that facilitates browsing and searching for the actual History List messages.
    1. MESSAGE_ID
    2. OBJECT_ID: The ID of the report or the dataset
    3. OBJECT_NAME: The name of the report or the dataset
    4. PROJECT_ID
    5. PROJECT_NAME
    6. USER_ID
    7. OBJECT_OWNER_NAME
    8. MESSAGE_OWNER_NAME
    9. PARENT_ID
    10. RESULT_ID: We may be able to use this. This corresponds to the CONTENT_ID column in the DSSCSCONTENT, and the DSSCSRPTCACH table
    11. START_TIME
    12. FINISH_TIME
    13. CREATION_TIME
    14. MODIFICATION_TIME
    15. TRIGGER_ID: If the history message was created by a subscription this column will contain the ID of the schedule Object. I've pressed the tech support team for this information. I am not sure how reliable this information is yet.
    16. SUBINST_ID
    17. FOLDER_ID
    18. FOLDER_NAME
    19. OBJECT_DESC
    20. MESSAGE_STATUS: The status of the history message. For example, "Ready", "Execution Error", etc. I've pressed the tech support team for this information. I am not sure how reliable this information is yet.
    21. MESSAGE_TYPE: The format (graph, grid, grid/graph, etc) of the History List message. I've pressed the tech support team for this information. I am not sure how reliable this information is yet.
    22. REQUEST_STATUS: Indicates whether the user has viewed the message (read) or not (unread). I've pressed the tech support team for this information. I am not sure how reliable this information is yet.
    23. REQUEST_TYPE: The type of object that was run to create the history message. For example, "Report", "Report Services Document" etc. I've pressed the tech support team for this information. I am not sure how reliable this information is yet.
    24. CLIENT_TYPE: The client component from which the message was created for example Mobile, Web, Developer etc. I've pressed the tech support team for this information. I am not sure how reliable this information is yet.
    25. LOCALE
    26. LAST_ERROR_CODE
    27. EXECUTING_NODE
    28. MESSAGE_TEXT
    29. MESSAGE_DISPLAY_NAME
    30. OBJECT_VIEW_MEDIA
    31. OBJECT_ABBREVIATION
  3. DSSCSCONTENT: This table stores history list related binary data such as prompt answers, SQL, manipulated XML, document instance stream, exported results (PDF, Excel or CSV). The DSSCSCONTENT table stores the "content" for history list messages. When a history list message is exported to a particular format (PDF, Excel etc), the corresponding export content is stored in the database. So if a large number of history list messages are generated for users, and users regularly export from these messages, the size of this table can increase quickly. Columns:
    1. CONTENT_ID: This seems to correspond to the RESULT_ID column in the DSSCSMSGINFO table
    2. SUB_ID: https://community.microstrategy.com/t5/Server/TN40349-What-does-the-record-of-the-DSSCSCONTENT-History-List/ta-p/190363
      1. 1: Result SQL
      2. 2: Prompt Answers
      3. 16: PDF
      4. 32: Excel
      5. 64: CSV
      6. 128: Document HTML
      7. 256: Document Streams. Stream file was used. The column SUB_ID = 256 of the DSSCSCONTENT table means that a Report Services Document was sent to the History List. Therefore, a stream file (a file read or written sequentially) is created. In a flat file based History List, a stream file gets created into the Inbox folder when a Report Service Document is sent to the History List. In the case of a database-based History List, when a Report Services Document is sent to the History List, the data corresponding to the Report Services Document History List gets saved in the DSSCSCONTENT table and the column SUB_ID value is defined as 256.
      8. 512: Settings
      9. 1024: Report Result Definition
      10. 2048: Result Cache
      11. 4096: Flash
      12. 8192: Document Result Binary
      13. 16384: Flash in PDF Container
    3. SLICE_ID
    4. VAL_SEQ
    5. REF_COUNT
    6. CONTENT_VALUE
  4. DSSCSRPTCACH: Starting MicroStrategy 9.2.0, DSSCSRPTCACH table was introduced as a dedicated table to store report caches only. In the past all the MicroStrategy objects related to History list caches management (including report caches) were stored in the DSSCSCONTENT table. Examples of the objects that are still being stored in the DSSCSCONTENT table are: Result SQL, Prompt answers, View settings, etc. The table structure look exactly the same as the DSSCSCONTENT table. Columns:
    1. CONTENT_ID
    2. SUB_ID
    3. SLICE_ID
    4. VAL_SEQ
    5. REF_COUNT
    6. CONTENT_VALUE

What is the purpose of the DSSCSRPTCACH table?

Starting MicroStrategy 9.2.0, DSSCSRPTCACH table was introduced as a dedicated table to store report caches only. In the past all the MicroStrategy objects related to History list caches management (including report caches) were stored in the DSSCSCONTENT table. Examples of the objects that are still being stored in the DSSCSCONTENT table are: Result SQL, Prompt answers, View settings, etc.

This new schema allows MicroStrategy suite to deliver better performance in the response times when running SELECT, INSERT or UPDATE statements against the History List database.

When users have the option to save history report caches to database, the Intelligence Server backs up the cache content referenced by History List messages and it effectively de-couples History List and caches. When History caches are deleted from MicroStrategy Desktop either via the cache Monitor or an administrative task, history caches are removed only from the file system. Content that is duplicated to the DSSCSCONTENT (in 9.0.x) and DSSCSRPTCACH (in 9.2.x and later) table is not deleted and the history list messages that reference this content continue to work. When the last history list message referencing the cache content is deleted, the duplicated cache content in DSSCSCONTENT/DSSCSRPTCACH table will need to be cleaned up otherwise it can lead to unmanaged database based history list. Administrators can make use of the 'cleanup history list database' scheduled administrative task to take care of this. Refer to the following MicroStrategy Knowledge Base document for more information on this task. Starting MicroStrategy 9.2.0, DSSCSRPTCACH table was introduced as a dedicated table to store report caches only. In the past all the MicroStrategy objects related to History list caches management (including report caches) were stored in the DSSCSCONTENT table. Examples of the objects that are still being stored in the DSSCSCONTENT table are: Result SQL, Prompt answers, View settings, etc. This new schema allows MicroStrategy suite to deliver better performance in the response times when running SELECT, INSERT or UPDATE statements against the History List database.

How can we control the size of the DSSCSCONTENT?

The DSSCSCONTENT table stores the "content" for history list messages. When a history list message is exported to a particular format (PDF, Excel etc), the corresponding export content is stored in the database. So if a large number of history list messages are generated for users, and users regularly export from these messages, the size of this table can increase quickly.

To control this size growth, administrators can limit the maximum number of history list messages per user, as well as implement a schedule to clean up old history list messages (which will cause the corresponding export content to be deleted). To limit the maximum number of history list messages per user:

  1. Launch MSTR Desktop
  2. Connect to appropriate project source
  3. Right click on the appropriate project source
  4. Select Configure MicroStrategy Intelligence Server
  5. Click on History settings on the left
  6. Click on General
  7. Change the "Maximum number of messages per user" setting to an appropriate value
  8. Change the "Message lifetime (days)" to an appropriate value.

I think that these settings can be changed per project, and probably there other settings that can be changed via the Web Preferences screen as well.

To implement a schedule to clean up old history list messages: NEED TO COMPLETE THIS.

Additionally, by default the History List Database feature would also automatically backup report caches that are associated with the history list message to the database. From MicroStrategy 9.0.2 a new setting has been introduced to allow users to select whether the history cache files need to be backed up to the History List database, or whether they can only be retrieved from the file system. Administrators wishing to verify whether this is the case can check if 'Backup report history caches to database' is selected under MicroStrategy Intelligence Server Configuration > History Settings > General > Repository Type > Database Based:

  1. Launch MSTR Desktop
  2. Connect to appropriate project source
  3. Right click on the appropriate project source
  4. Select Configure MicroStrategy Intelligence Server
  5. Click on History settings on the left
  6. Click on General
  7. Look at the check box "Backup report history caches to database"

Note that disabling this setting does not remove existing caches from the History List database. Users should note that matching only caches only use the file system and are never backed to the History List Database.

How can we deal with unused report caches from the DSSCSCONTENT table in History List Databases after MicroStrategy 9.2.x?

After upgrading a history list repository from MicroStrategy 9.0.x to MicroStrategy 9.2.x or higher, expired report caches still remain in the DSSCSCONTENT table after they are no longer needed. These report caches cannot be removed after running the Administrative Tasks "Clean History List Database" or "Delete History List Messages." The unnecessary excess data in the DSSCSCONTENT table can then cause issues with the history list database running out of space.

Starting in MicroStrategy 9.2.0, the DSSCSRPTCACH table was introduced as a dedicated table to store report caches only. In previous versions all the MicroStrategy objects related to History list caches management (including report caches) were stored in the DSSCSCONTENT table. During the upgrade of the History List Repository, if the option "Copy History List content" is unchecked as shown below, then the History List management mechanism will recognize the fact that there are report caches that are contained in the DSSCSCONTENT table and will use the new table DSSCSRPTCACH for all newly created report caches.

The History List management mechanism will continue to use the existing report caches in the DSSCSCONTENT table until all of the existing report caches in the DSSCSCONTENT tables are expired. After the report caches used in the DSSCSCONTENT table are expired they will be removed through the Administrative Task "Delete History List Messages." If the history list messages have been manually deleted from the DSSCSMSGINFO table then there will be no association back to the report caches in the DSSCSCONTENT table, therefore they will not be deleted by Administrative Tasks.

If the DSSCSCONTENT table contains rows with SUB_ID 2048 (report cache) verify to see how many report caches are no longer being used by history list messages by running the follow query:

SELECT COUNT(CONTENT_ID) FROM DSSCSCONTENT WHERE SUB_ID = 2048 AND CONTENT_ID NOT IN (SELECT(RESULT_ID) FROM DSSCSMSGINFO);

If the value returns something other than zero then there remains report caches in the DSSCSCONTENT table that are no longer needed. To delete these rows run the query:

DELETE FROM DSSCSCONTENT WHERE SUB_ID = 2048 AND CONTENT_ID NOT IN (SELECT(RESULT_ID) FROM DSSCSMSGINFO);

Manually editing values in the MicroStrategy History List Repository incorrectly may cause serious, project-wide problems that may make your project unusable. Since these are user-initiated changes, they are not covered by any MicroStrategy warranty. Users are strongly encouraged to backup the MicroStrategy History List Repository prior to any alteration.

What are different ways to archive report data?

As data changes in the warehouse, new executions of MicroStrategy reports naturally return different results to reflect the most current data. As warehouse data loads occur and MicroStrategy Intelligence Server report caches are invalidated, old report results become unavailable. However, project requirements sometimes include the ability to access old report results.

  1. A common method of keeping old report results is to include data versioning in the project's data model. Time-sensitive facts can be 'tagged' with version information within the database, and the version information can then be architected into the MicroStrategy project. The data version can, then, be included in reports. Because the versioned data is always held in the data warehouse, old report results from any time period can always be accessed. These snapshots of data can also be compared with each other for trend analysis.
  2. Another method of keeping old report results is to use the exporting feature in MicroStrategy Web and MicroStrategy Desktop. When reports are executed, users who wish to refer to this data at a later time can export the result set (to Microsoft Excel, Microsoft Word, Microsoft Access, a text file, an HTML file, or a PDF file). This exported result set can, then, be examined at a later time.
  3. A third method of archiving data is to use the datamart feature in MicroStrategy Intelligence Server. Reports can be defined to insert the result set into a new or pre-existing database table. The result set will, then, be available as long as the datamart table exists in the database. The accumulated historical data in the datamart can be used by other applications for comparative analysis or, the datamart table can be architected into a new or existing MicroStrategy project for analysis.
  4. Yet another method for archiving data is to use MicroStrategy Narrowcast Server to deliver report results in an e-mail to an end user. Users interested in keeping old report results for later reference simply have to keep the e-mail.
  5. MicroStrategy Intelligence Server 9.x has the ability to archive scheduled report results in a user's history list. Archived reports can then be accessed at any time so that old report data can be examined. When the archived data is retrieved, restrictions on analytical operations will be enforced. These archived reports are created by the MicroStrategy Intelligence Server scheduler; when reports are scheduled, the schedule request can be tagged to create an archived history list message. This tagging of schedule requests is performed differently in MicroStrategy Web and MicroStrategy Desktop.

How can we do Warehouse-side versioning / archiving?

The data archiving feature discussed above is not meant to be a replacement for including data version information in a project's warehouse and data model. Archived history list messages are easy to create, but they are limited in the analysis that can be performed on them; warehouse-side data versioning can provide more flexible reporting and analysis capabilities for time-sensitive information. In addition, since databases are more specifically designed for data storage, and time-sensitive information would be stored once instead of redundantly in the form of multiple reports in multiple user's history lists, warehouse-side versioning will tend to be a more efficient and scalable solution to storing time-sensitive information than history list data archiving. Finally, any time-sensitive data in databases are persistent in addition to being always and globally available. Data archives are only available to end-users if they had subscribed to the report and kept the archived history list message in their history list. History list messages are controlled by the end-user, so an end user can permanently lose archived data by simply deleting a history list message.

MicroStrategy Intelligence Server-side data archiving is best suited for situations in which data storage and analysis requirements are low. An example of this would be for weekly scheduled reports, where the project may require that users be able to come back after a long interruption and take a look at any old reports that had been executed previously; but then delete the History List message after viewing. Another appropriate use of data archiving would be when users sometimes want to take a look at a limited set of old report data and compare them with recent data. Note that data archiving would only allow for side-by-side comparison of reports only and does not allow any in-depth analysis of data movement over time.

Is it possible for some subscribed reports to create archived History List messages, while other subscribed reports create standard History List messages?

Yes. The 'decision' to make a subscribed report create a data archive occurs when the user subscribes to the report. At the time the user subscribes the report, if the 'Overwrite old results' setting is enabled, then that particular report subscription will create standard History List messages for that user. Similarly, if the 'Overwrite old results' setting is disabled at the time the user subscribes to a report, then that report subscription will create archived History List messages for that user. Information as to whether or not to create an archived history list message is saved into the metadata as part of the definition of the schedule request. Schedule monitor in MicroStrategy Desktop/Developer will not show information as to whether or not a particular schedule request will create a data archive; this information can be obtained using the COM API in the MicroStrategy SDK.

The 'Overwrite old results' setting is a project-level setting and will apply to all users. However, whether or not a particular report subscription will create an archived History List message depends on the state of this setting at the time the subscription was created.

How can we delete the History Caches from disk?

When a History List message is created, the History List content (cache) is stored on the file system as well as in the History List repository. If users wish to keep the History List content in the History List repository for long term usage, the History list content should be deleted from the file system first so it is not loaded in memory every time MicroStrategy Intelligence Server starts up. When the administrator wants to access the content of a History List message that no longer has the cache file on disk, the cache will be loaded from the History list repository on demand (as soon as the user clicks on the History List message).

To delete the History List cache from the file system, the administrator should create an administrative schedule to delete only "History Caches". This will ensure the History List content is only deleted from the file system but still remains in the DSSCSCONTENT table (one of the three History List repository tables).

The process described in the above section should only be used if Database Based History List is needed as long term storage medium otherwise orphaned rows may remain in the DSSCSCONTENT table.

How can we fish out the data from the history list tables?

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License