Hi @Evgeny Shvarov

AnalyzeThis.Utils.cls has a method called RefreshCube.

At one point, this was briefly in then UI. We took out the UI reference since we weren't (and still aren't) sure how this should fit into AnalyzeThis. Historically the goal was to be able to quickly get a personalized preview of DeepSee. It was not intended to be an automatic cube generator. The goal was to let people see the benefit of DeepSee, but then allow them to create their own cube and no longer rely on the generated cube from AnalyzeThis. However, I do know of multiple cases where people are using it as you explain in this case and would like to refresh the data once a new CSV has been produced with updated data.

Please let me know your thoughts on the Pros vs Cons of using the AnalyzeThis generated cube VS using your own cube once you have a model you like and would like to continue using.

Hi Mike,

As you have seen, Class files are stored within Caché and not on the file system. We have Studio hooks available as documented here. These allow you to write code to perform the export and import automatically as you interact with your classes in Studio. After files have been automatically exported, you will be able to run Git commands to commit and push your changes as desired.

Instead of doing all of this yourself, there does seem to be an Open Exchange app available that does something like this. I have not used this before, but @Alexander Koblov may be able to add more details of how complete it is

Peter
 

You can just check $$$ISERR(sc) directly here, you do not need to run it through $system.Status.GetErrorText(sc)  first.

$$$ISERR(status) will compile into ('status). In the case where sc=1, status will become = "". This means that 'status will evaluate to true when sc=1, which means it will think there is an error when there is not.

USER>set sc=1
 
USER>set status=$system.Status.GetErrorText(sc)
 
USER>zw sc
sc=1
 
USER>zw status
status=""
 
USER>w ('status)
1
USER>w ('sc)
0

Hi Lawrence,

I suggest opening a new WRC with Support. Here are a couple first step diagnosis options that can be helpful, but without a deeper understanding of the DeepSee Engine, it may be difficult to debug or correct the issues.

1) Run MDXUtils and produce a performance report.

This tool will kill your DeepSee Cache and then execute the query. It will log statistics about the query and the cube. It then runs the query a second time which will use the Cache that was just generated. Depending on the query, this can often be much faster.

2) Run DeepSeeButtons.

This will give a snapshot of your entire DeepSee environment. It will also look for recommended configurations and alert if the recommendations are not followed. For example, if the Database your Cache globals are stored in is journaled, this can negatively impact query performance. Lots of globals are modified during query execution, so it is recommended to not have this journaled. If DeepSeeButtons detects that the Database your DeepSee Cache is in is journaled, it will create an alert.

As I mentioned earlier, it is probably a good idea to contact Support, but these are two good steps to start with (and the WRC will probably ask for these as well)