TM1 Forum

All,

I had never used the drill functionality prior to this week as previously hadn't had a requirement to do so but then a requirement appeared so out came the "manuals"...

I have successful created and assigned 2 "dynamic" drill processes to a cube that work perfectly as desired, 1 summary cube that is fed from 2 nearly identical cubes, 1 for "home" customers and one for exports. The drill process uses attributed on a dim in the summary to decide which cube to drill to and the drill process updates the subsets int hat view to specify exactly what it relates to... spot on.

The question is (and I know this is sort of opposite to drilling) can I drill into 2 separate cube views at once when I drill in the summary on "total customers" so that it will open the "home" and export cubes in one go?
I have updated another drill process to create both cube views in the prolog but then comes the "returnviewhandle"... obviously the initial one is in the TM1 generated statements so I have tried sticking the equivalent for the other cube in the epilog after (and before) the generated statements but TM1 only pulls up the view from the generated statements.

Is this a command that can only be initiated by a generated statement? Is there anyway around it?

Again I know that drilling would generally be trying to narrow down a point rather than this slightly unusual purpose and its not the end of the world if we can't solve it but it would be nice to know.

Cheers

Hi there,

Maybe you could have a navigation from the first view result of the drill down to the equivalent view in the second cube you intended to open as well ?
Both views will not open at the same time but it could be a workaround ?


Hope this helps,

I know this is an old post, but did you ever solve this? I have same need to open two separate cube views through a drill. Two RETURNVIEWHANDLE functions in the epilog did not manage to do it.

To be honest I don't remember posting this topic and from looking at the question I can't recall what project/customer it would have been for.

I've tended to avoid drill processes where possible and in place of that use the URL API but I do the vast majority of my User Interfaces via TM1 Web which allows myself a greater flexibility; I've always felt that a cube view is a bit too "demanding" to navigate for most of my user bases - so I tend to create extra "drill websheets" that of course can show multiple cubes together; but this only works if you can put your hyperlinks somewhere on the sheet that you want to navigate from. I often use the hyperlink() excel formula in a dbrw; which works and looks great as long as you don't need to write back via that cell.

And when it comes to drilling in to a database... well don't get me started on how ugly the pop-up screens are for that!
Again I would use websheets for that which are built on temporary cubes - specific to the user who is opening them.

I should caveat the above by saying I'm not against drill processes and think they are excellent functionality which I do use for the right people but I find that in my experience; creating a more customised web based UI is preferable for a large portion of user bases I have encountered.

Very interesting. We are pushing to expand websheet usage and what I have is an active form based on one cube but calculates the variance with another cube...

DBRW(cube1, , , ) - DBRW(cube2,,,)

This works fine, but takes a little trickery to get the drill to work. This websheet compares the cubes at a high level. If there is a variance, the drill loads and displays another cube which compares the two cubes side by side at a more detailed level. From there, we drill back to some source cubes for each cube reference. As an added bit of complexity, the top cubes do not have the same dimensionality.

We're not tied to drill-throughs. We use them because they are fast and, through customization, we control what is presented, but if we can do the equivalent through web-sheets, that would be preferable overall.

Thanks.