TM1 Forum

Are the threads going into a wait state while one finishes? If so, then probably a locking issue. A likely culprit is if this process is making any metadata changes.

This is pretty much exactly the use case that bedrock.hier.export.script was developed for. The process exports as TI code the script required to build dimensions (or hierarchies). There are options to filter on particular elements, attribute definitions, etc. It's a super easy way to generate this...

While you certainly can do it manually, it is error prone, and it doesn't catch things that are data and metadata related. Using Beyond Compare or WinMerge tools are great for processes and rules, but when it comes to comparing dimensions, or attribute data, or even cube data, that is where the man...

There are a number of different methods, many of which are elucidated on this forum. However, working two simple scenarios: 1) migrating everything from DEV to Prod Shutdown both servers (or run Save Data on DEV) and copy the DEV\data folder to PROD\data folder. Restart Prod instance. 2) migrating s...

This has been awhile, but needed to update it (got a question on it today). If the subsets and the view exist and are updated, not created fresh, the drill through works fine with customized subset and view definitions. To avoid user conflicts, we added views on each cube and subsets on dimensions w...

@tomok

I think this one is for you.

Beyond Compare (BC). I've used winmerge, but BC is better at matching up lines without false positives and tons of features. Use it for awhile and you'll throw rocks at winmerge. We have four environments (D, Q, S and P) that our code moves through and BC sessions are easy to setup to allow quick co...

I do not know if this is what lotsaram was referring to, but an alternative is to use SLEEP(n) after the ExecuteCommand where n = milliseconds as another way of giving PS time to complete. With ExecuteCommand, if something goes wrong in the called script and it gets hung up, your TI will sit there p...

We have found that if the value of a session variable changes during a session, any processes executed through RunProcess will use the original session variable value setting . The value changes when the client logs out and back in. All processes executed directly as part of the user's current sessi...

If an account has different spread methods depending on the BU, this cannot be done in a regular cube view with both dimensions on the rows. It can be done with the BU as a title dimension.

You might can in a websheet.

Have not seen it mentioned, but the Bedrock White Papers are excellent resources as well.

Wim's MDX page is very good.

In my experience this happens when a view has been saved with static subsets or selected elements. Someone then deletes these elements effectively returning a null set and the view breaks. There are probably other reasons but the above is probably a frequent occurrence for newer users who do not us...

I may have missed it, but how are [daystaken] and [sales] loaded? From another cube via rules? Either way, seems obvious your measure should be sliced by the Banding. Adding individual measures to achieve this is really defeating the purpose and advantages of dimensional modeling and TM1. What happe...

Why not add another dimension for Bandings since that seems to be the way you want to be able to slice the data?

Did you try DIMIX( cDim |‘:‘| cHier, vEle) ? Do not know if this directed at my response, but I was not really clear. Where I'm using the temporary dimensions is when generating an email table of incorrect mappings/etc and, for instance the same account pops up 200 times. Only wanting one line for ...

I tested this and compared performances for DIMIX against SubsetElementGetIndex in a large dimenson (having more than 10k members). The result is DIMIX is 400 times faster than SubsetElementGetIndex. Hence, when I replaced DIMIX with SubsetElementGetIndex, my processes never finishes at all and kee...

Okay, possible problem with the feeder. When the load was slow, did you test a subsequent update immediately after the first? If so, what were the results? When the process ran quickly after adding back the rules, was the cube unloaded prior to the run? Are you using persistent feeders? (if yes, may...

I have not seen that type of performance difference in this type of update and have a dimension of over 475,000 elements updating four attributes. The TI is reading from an Oracle datasource and runs the update in approximately 90 seconds give or take. Do you have a rule file on the attributes cube ...

It also appears you are doing a lot of addition in the rule. May consider breaking this gigantic rule into smaller ones by creating a consolidation that has components for each DB() call made. Native TM1 consolidations are much faster than rule-driven addition I believe you'll find.

So the MDX Views are not the magic I was hoping for to force my TI process to loop through the source in a way I want it to then. Thanks for the clarification. That is an interesting conclusion drawn from lotsaram's post. Suspect that you are not fully understanding what we are saying. In a traditi...