To automate this with built-in DeepSee methods, please see documentation for %ExportPDFToFile. This can be used in a task and can be saved/emailed on a scheduled interval. Using other utility methods such as %GetMDXFromPivot can allow you to supply a list of pivot names and programmatically get the MDX to supply into the Export method.

Hi Damian,

I believe there are a few cases where this can happen - most of them involving the use of source control. Do you have source control enabled on all of your namespaces except ENSDEMO?

I would suggest opening a new WRC for this issue since there are a few possible causes and we may need to know a little bit more about your system.

DeepSee does not have anything built in to automate this behavior. Depending on how the relationship is defined, this could cause significant overhead (also if more than 1 relationship is defined, this grows even more). The recommended way of doing this is exactly as you have done.

An alternative approach is to implement %OnProcessFact and have it process any related cubes that need to be updated. The good thing about this approach is that it saves you time during your main application while saving records, but the downside is that it also requires CubeB to be synchronized at the same rate as CubeA.

Using the Cube Manager, you would be able to write some "pre-synchronize code" that would run queries to find records in CubeA that need to be updated and calling ##class(%DeepSee.Utils).%SetDSTimeIndex() here. This is quite similar to what it sounds like you are doing now, but this lets you avoid using triggers and building this process into the Synchronize itself.

Thanks for the input on this. I have considered these negative consequences as you describe. I am pulling my data from REST services, so it would be perfectly fine for me to delete all my data if need be. Perhaps once the early phases of development are finished these diffs will become less active and not a problem.

The second reason is that I have been developing on both Caché 2017.2 and InterSystems IRIS. The storage definition changes slightly based on which one I am using, so it creates a little bit of noise, but it is ultimately manageable. Perhaps doing development across products is not recommended, so that could also be the answer

You can accomplish this by using pivot variables. By using this approach, the pivot variable can act as the Key for two different date dimensions. Example:

Pivot variable with value of &[2017].

[Date1].[H1].[Year].$variable.Year

[Date2].[H1].[Year].$variable.Year

On your dashboard, you would want to use the Apply Pivot Variable control instead of the Apply Filter control. 

I just tried adding your element to ZENDemo.Home.cls SAMPLE page, and it worked just fine. I added it after the element with id "description"

<html id="description" width="800" OnDrawContent="DrawDescription"/>
<select id="condition" label="Condition" valueList="&lt;,&gt;,=,≤,≥" displayList="&lt;,&gt;,=,≤,≥"/>

Perhaps include a picture of what you are seeing?

List levels can be confusing because as defined, a single fact can have multiple members. This means that you may see counts higher than the total number of facts in your cube. This can be quite the surprise if you are not expecting it.

Based on the complexity of these types of levels, I would not suggest using them in dimensions with other levels. There may be a particular case where you need this, but I think it would be much safer and a lot more easy to understand if the other levels were placed in different dimensions.

Hi Arutunyan,

Let me know if this properly answers your question. If it does not, please consider adding an example.

We can use the property FullName as an example. Some values for this may be "Gevorg,Arutunyan" or "Steiwer,Peter". You can make a dimension with a source expression using $piece to extract the Last name or the First name. In this case, you may want a single dimension with 2 levels. The first level is "Last Name" that uses the expression: $piece(%source.FullName,",",1). The second level can be called "FirstName" and it can use the expression: $piece(%source.FullName,",",2).

Documentation says that if you use Target=* on your print PDF control, you can "print your dashboard". This option will simply create one PDF that contains each of your widgets printed as they would normally print. So if you are looking for 1 PDF, this may be the option for you. If you want to save an exact copy of what you see on your dashboard, as Alessandro points out, the browser Print option may be best.

I am not sure if you have already explored this or if you had a print control on each widget previously.

Hi Derrek,

I suggest taking a look at the IIF Documentation. I think this is what you are looking for. Here is an example:

>> WITH MEMBER [Measures].[TestIIF] As 'IIF((([Measures].[Amount Sold]>500) AND ([Measures].[Amount Sold]<3000)),[Measures].[Amount Sold],"")' SELECT {[Measures].[Amount Sold],[Measures].[TestIIF]} on 0,NON EMPTY [Product].[P1].[Product Category].Members ON 1 FROM [HOLEFOODS]
 
                             Revenue              TestIIF
1 Candy                       $162.49                    *
2 Cereal                      $402.61                    *
3 Dairy                       $105.95                    *
4 Fruit                       $977.62               977.62
5 Pasta                     $1,408.68             1,408.68
6 Seafood                     $238.70                    *
7 Snack                     $4,195.20                    *
8 Vegetable                   $552.95               552.95

Unfortunately, from what I can tell, it does not seem like we parse the TARGET setting. This means that if you want to apply the setting to multiple Widgets, you will need to create multiple SETTINGS parameters

basic_dashboard_url&SETTINGS=...;&SETTINGS=...;&SETTINGS=...;...;

This being said, if you want the setting applied to ALL widgets, removing TARGET will apply the setting to all widgets. You can also set TARGET=* to apply to all widgets as well.

Hi Derrek,

I generally recommend using the "All Member". This will allow the proper aggregation function from the measure to be applied to your total. This may cause your % of Total to not display the desired results and you may be required to create a new measure to display the % of Total instead of using the column summary option. The summary options will base their results on the data inside of the table, not on the data behind the table. In some basic cases, they summary options will give the desired results, but in more complicated queries, they will not.

Have you tried creating a "Searchable Measure"? This may partially solve your problem. Checking the "Searchable" option in Architect for a measure will make the measure available within a Named Filter. It will also allow you to create a filter control on a widget with the measure.

This is not available for calculated measures because creating a "Searchable" measure creates a special index on that measure (this index is populated at build/synchronize time).

Samuel is correct, using NOW-1 on a Day level will give you the information from yesterday.

For the second part, please see the following two queries:

>>select PERIODSTODATE([DateOfSale].[Actual].[MonthSold],[DateOfSale].[Actual].[DaySold].[NOW]) on 1 from HOLEFOODS
 
 
1 Mar 1 2017                              *
2 Mar 2 2017                              *
3 Mar 3 2017                              *
4 Mar 4 2017                              *
5 Mar 5 2017                              *
6 Mar 6 2017                              *
7 Mar 7 2017                              *
---------------------------------------------------------------------------
Elapsed time:       .009242s
>>select COUNT(PERIODSTODATE([DateOfSale].[Actual].[MonthSold],[DateOfSale].[Actual].[DaySold].[NOW])) on 1 from HOLEFOODS
 
 
COUNT                                     7
---------------------------------------------------------------------------
Elapsed time:       .006043s

Ah yes, creating some new dimension, for example, called "IsDifferent" and having values of 0 or 1 would definitely work. If this dimension makes sense within your cube, then it would be OK to add (for performance and simplicity reasons). If the case presents itself where you have another two dimensions you need to compare, you will need to add "IsDifferent2". This pattern may repeat based on the use case.

It would be possible to create a PlugIn that takes dimension names as parameters, which would allow you to dynamically compare values without needing to pre-define all of your combinations.