EducationSoftwareStrategy.com
StrategyCommunity

Knowledge Base

Product

Community

Knowledge Base

TopicsBrowse ArticlesDeveloper Zone

Product

Download SoftwareProduct DocumentationSecurity Hub

Education

Tutorial VideosSolution GalleryEducation courses

Community

GuidelinesGrandmastersEvents
x_social-icon_white.svglinkedin_social-icon_white.svg
Strategy logoCommunity

© Strategy Inc. All Rights Reserved.

LegalTerms of UsePrivacy Policy
  1. Home
  2. Topics

KB325314: In MicroStrategy 9.4.1 - 10.5, multi-source reports inherit the Report Pre/Post Statement VLDB setting only from the primary database instance


Community Admin

• Strategy


This article notes how multisource reports interact with pre/post statements.

SYMPTOM
Note: Changing the registry to a value of 0 will have the report pre-sql applied to just the primary database instance. Prior to Strategy 10.7, pre-statements were applied only to the primary database instance. However, in later Strategy versions, the pre-statements are now applied by default to all database instances in multi-source reports. Per our testing, setting the value to 0 restores the earlier behavior (where report pre-statements only apply to the primary database instance).
 
In Strategy versions 9.4.1 - 10.5, when executing a multi-source report, the Report Pre/Post Statement VLDB setting is only inherited from the primary database instance  
 
Suppose there are two database instances (DBI_A and DBI_B); in the primary database instance DBI_A, Pre-Report SQL is set to: “set current refresh age=any”

  1. DBI_A (Primary)
  2. DBI_B

 
As given below,  it is seen that the Report Pre/Post Statement VLDB setting defined on DBI_A gets applied to the report SQL passes that run against secondary database instance DBI_B as well. The expectation is that no Pre-Report SQL is executed against secondary database instance DBI_B as nothing was defined there.
Snippet from the multi-source report SQL is as below:


SQL Statements:

Pass0 - [DBI_A] 
Query Execution: 0:00:00.00 
Data Fetching and Processing: 0:00:00.00 
Data Transfer from Datasource(s): 0:00:00.00 
Other Processing: 0:00:00.02 
set current refresh age=any

Pass1 - [DBI_B] 
Query Execution: 0:00:00.24 
Data Fetching and Processing: 0:00:00.00 
Data Transfer from Datasource(s): 0:00:00.00 
Other Processing: 0:00:00.47
set current refresh age=any


//Rest SQL passes all run against secondary DB Instance (DBI_B) only.

 
CAUSE
This is a known behavior in Strategy versions 9.4.1 - 10.5. 
  
ACTION
This issue has been addressed in Strategy Secure Enterprise 10.6 and in Strategy 10.4 Hotfix 3. Upgrade to this version to take advantage of the fix. 
 
NOTE: In Strategy 10.4 Hotfix 3, the following steps need to be implemented for the new behavior to be applied i.e., for the fix to be applied. 
 
Windows

  1. Stop the Strategy Intelligence Server.
  2. Open the Windows Registry Editor. 
  3. Add a new DWORD called " PrePostReportMultiSource " with a value of 1 in the following registry location (a value of 1 enables the feature and value of 0 disables it)
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Strategy\DSS Server\Castor]

  4. Close the registry and start the Strategy Intelligence Server
ka04W000001Ix1EQAS_0EM440000002Byi.jpeg

Linux/UNIX 

  • Stop the Strategy Intelligence Server
  • Open the MSIReg.reg file in a text editor (this file is located in the <MSTR_HOME> folder; /var/opt/Strategy/ by default)
  • Locate the following entry:
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Strategy\DSS Server\Castor]

  • Add a new entry as follows: (a value of 1 enables the feature and value of 0 disables it)
    
    "PrePostReportMultiSource"=dword:00000001

  • Save and close the MSIReg.reg file. The final registry entry should look similar to the following entry: 
ka04W000001Ix1EQAS_0EM440000002Byg.jpeg
  • Start the Strategy Intelligence Server

 
 
The Strategy Internal Reference Number for the issue discussed in this article is DE25878.
 
Registry Modification:
WARNING:
Modifying registry values incorrectly may cause serious, system-wide problems that may require the re-installation of Microsoft Windows or Strategy installations on UNIX/Linux operating systems. Any edit of the registry is done at the user's own risk. Since these are user-initiated changes, they are not covered by any Strategy warranty. If using Microsoft Windows, the user should backup the registry and/or update an Emergency Repair Disk (ERD) prior to alterations.
 
 


Comment

0 comments

Details

Knowledge Article

Published:

May 26, 2017

Last Updated:

September 22, 2022