Dimension without any elements / members

[hunterforcognos]

Recently, I was interviewed for TM1 and was asked whether you could create a dimension without any members. I said that Dimension editor would throw an error stating that the dimension should have at least one element. However, the interviewer mentioned that it is possible and did not tell me how. I am really intrigued by this query. Can someone please pass some inputs? Have you ever done this before? Also, what was the business need to have a dimension without any elements in it?

Thanks in advance for your help!

[qml]

DimensionCreate.

[declanr]

As QML pointed out you can use TI or you could add a .dim file to the directory and manipulate it to contain no elements.

At the end of the day there is (almost) no reason to need to have empty dimensions but its a quick and easy question to ascertain whether someone understands the fundamentals of TM1 in an interview scenario.

[Duncan P]

Of course if you are allowed two steps in Architect you can create it with one element, then edit the structure and remove the element. It will then save OK with no elements.

[EvgenyT]

As guys pointed out, its possible.. while you cant manually create then save dimension without inserting at least one element, you can get around it with process or removing existing elements then saving it.

Its a bit inconsistent, wouldn't you agree guys?

ET

[Alan Kirk]

As guys pointed out, its possible.. while you cant manually create then save dimension without inserting at least one element, you can get around it with process or removing existing elements then saving it.

Its a bit inconsistent, wouldn't you agree guys?

Yes and no.

There's an application that I'm writing at the moment. (Three, actually, which highlights the issue well for reasons that I'll explain shortly.) And one of the things that I've been contemplating with those three is:

"How much time should you put in to protect users from executing commands stupidly, thoughtlessly, and/or out of context, and what's the return in value for coding that protection?"

What I find is that with the GUI-intensive one, the one where you can do little more than click on buttons and enter some text or select menu items or buttons... it's really quite easy to put the coding in to intercept user stupidity.

The most complex one, which is a front end to a home brewed GL system, well, that one needs to be very flexible and powerful but that in turn means that users have the potential to do stupid things, some of which I've thought of, some I won't have.

And it's exactly the same with this in TM1. Creating an element-free dimension is something that is potentially stupid and/or reckless, especially when you start trying to add it to a cube. You can have consequences which are both undesirable and potentially quite bad.

In short, if you know what you're doing, you shouldn't do it.

And if you don't know what you're doing, then you probably shouldn't be trying to do it unless it's in a personal development environment where things can crash happily and do no real harm.

Should Iboglix have spent the time writing code to ensure that there is no way, no how that you can have an empty dimension?

While I'm prepared to criticise when criticism is due (and the Performance Muddler team would probably say "when it's not due as well", but we'll agree to disagree on that point) I'm not going to bag Iboglix for this one. I lean towards "no" in answer to that question, simply because with a system this flexible / powerful it is simply impossible to invest the resources in intercepting every single idiotic thing that a user might potentially do. It's just like with a car. You build in as many safety features as the average punter needs, but you can't protect someone from driving the wrong way down a one way street or following their GPS off a cliff. Having an elementless dimension is like the one way street analogy. You might get away with it, you might not, but it shouldn't be up to Ford, Mitsubishi, Holden, BMW or whoever (or in this case Iboglix) to build something to stop you from doing it.

[EvgenyT]

Well-rounded argument here Alan, Thank you!

[java_to_tm1]

... but you can't protect someone from ... following their GPS off a cliff.

Loved that one, Alan!

I create my dims (and attributes) in TI processes (it helps me in migrating stuff between my DEV / QA and Prod environments).
And I always immediately add a minimum of one element to the dim immediately after creation: either a 'Total of _' element for regular dimensions or the measure elements (if it is a measure dim).

This single element lets me create my standard MDX subsets (An 'All Members' subset and a 'Level 0' elements) and my views.

When my source data has undergone drastic changes, and I need to reload my dims from scratch: I'd like to have the

Code: Select all

DeleteAllElements 

function to call in my Prolog.
It would be entreily my fault if i then refuse to do the

Code: Select all

DimensionElementInsert 

in my Metadata.

I'd hardly go around blaming TM1 for giving me the chance to showcase my stupidity!

[Duncan P]

Try

Code: Select all

SubsetCreateFromMDX( subset_name, mdx_expression, dimension_name_in_case_mdx_returns_nowt );

which is still undocumented in 10.2 despite working in 10.1.

[hunterforcognos]

Thanks a lot all of you. I tried all the methods and they worked. Thanks again!

[Wim Gielis]

Try

Code: Select all

SubsetCreateFromMDX( subset_name, mdx_expression, dimension_name_in_case_mdx_returns_nowt );

which is still undocumented in 10.2 despite working in 10.1.

Thank you Duncan. The catch is that, if your MDX expression contains "nonsense" or inexisting formulas, the client will crash if you delete the subset manually.
If SubsetDestroy is used in TI, it does not crash.

[rmackenzie]

At the end of the day there is (almost) no reason to need to have empty dimensions ....

Temporary dimensions can be created, populated, analysed and then deleted as part of load processes without them ever having to be part of a cube. This sort of usage isn't the typical use of a dimension, but I'd say it isn't that rare either.

[declanr]

At the end of the day there is (almost) no reason to need to have empty dimensions ....

Temporary dimensions can be created, populated, analysed and then deleted as part of load processes without them ever having to be part of a cube. This sort of usage isn't the typical use of a dimension, but I'd say it isn't that rare either.

I agree that temporary dimensions have a place and I use them commonly. I also regularly use hidden dimensions for the purpose of creating picklists against. However as far as I read the OPs question it was regarding what purpose an EMPTY dimension would have in ongoing requirements.

[rmackenzie]

However as far as I read the OPs question it was regarding what purpose an EMPTY dimension would have in ongoing requirements.

Yes, sure. If the dimension isn't being used in a cube, and is being used as a temporary queue, or an array, or something similar; then it being in an empty state isn't really a problem.