TM1 Forum

Posted: **Wed Aug 05, 2015 9:09 am**

Hi guys,

I am on a consolidation Project. And we have alot of views which uses the same date subset. My subset has an only one item.('31.12.2014').
thats why, all my views has that date which is 31.12.2014. And ı saved all the views with that item.

Then later on, our customers wanted from me to open a new date to enter data. And ı added 30.06.2015 to the subset. Also they want all from me when they open the views they want to see the 30.06.2015 on the screen. But the point is ı saved all the screen 31.12.2014 at the first.

After all these , even though ı put the 30.06.2015 first and after that 31.12.2014 , all the screen is still open up as like 31.12.2014.

There is a TI process 'ViewTitleElementSet' this can be useful for me . But maybe ı have 200 view on this Project. Maybe there is another easy way

What do you think guys?

You create a subset. Then u add an element and save all the views. Then, open up that view you see that element . After that, u added a new element to same subset. You want to see new element first when you open the view. But , old element comes first.

Posted: **Wed Aug 05, 2015 9:21 am**

AliUgur wrote:Hi guys,

I am on a consolidation Project. And we have alot of views which uses the same date subset. My subset has an only one item.('31.12.2014').
thats why, all my views has that date which is 31.12.2014. And ı saved all the views with that item.

Then later on, our customers wanted from me to open a new date to enter data. And ı added 30.06.2015 to the subset. Also they want all from me when they open the views they want to see the 30.06.2015 on the screen. But the point is ı saved all the screen 31.12.2014 at the first.

After all these , even though ı put the 30.06.2015 first and after that 31.12.2014 , all the screen is still open up as like 31.12.2014.

There is a TI process 'ViewTitleElementSet' this can be useful for me . But maybe ı have 200 view on this Project. Maybe there is another easy way

What do you think guys?

I think there's something wrong with the way you saved your subset. Or, possibly, that the views do not in fact have the subset saved as part of the definition. I just did exactly the same thing; created a public, named subset, created a view using that subset in its title, saved the view. Then I added another element to the subset and resaved it. If I sort A to Z and resave it then the A element appears when I open the view. If I sort it Z to A and resave it then the Z element appears when I open the view.

You may want to post one of your .vue files and the relevant .sub file.

Posted: **Thu Aug 06, 2015 8:20 am**

Hi Alan,
thanks for reply . I tried the thing as you said. Before , I was not sorting it, A to Z or Z to A. Do you think that, thats why ıt was not working out?

Have a nice day..

Posted: **Thu Aug 06, 2015 9:02 am**

AliUgur wrote:Hi Alan,
thanks for reply . I tried the thing as you said. Before , I was not sorting it, A to Z or Z to A. Do you think that, thats why ıt was not working out?

I think it's more likely you weren't saving it after reordering. I just checked it out by manually cutting and pasting the elements to set the order, then saving; same result. It still worked as expected.

Posted: **Thu Aug 06, 2015 1:46 pm**

You are right. I tried on my VM . As you said and it worked. But ı have no idea why it didnt work on the server.

I just checked at the server. And ı added a new date element which is '31.07.2015'. And my other elements are '30.06.2015', '31.12.2014'.

And the order is like

31.07.2015
30.06.2015
31.12.2014

and ı saved the subset. And all the views ahs this subset. but before ı saved all the views as like 30.06.2015. So for tihs order ı expect the 31.07.2015 but on the Project which is in other server . Still open with 30.06.2015 What do you think about?
Maybe ı did something wrong before ı have no idea, but all my views has that subset..

Posted: **Thu Aug 06, 2015 2:05 pm**

AliUgur wrote:YWhat do you think about?

I think you are basically not doing what you think you are. It is possible to save a view, specifically selecting elements from a dimension, without using a subset. I am guessing you started the view with a subset but at some point you pasted this new item in and then clicked on save, which would save the view and have the effect of hard-coding those elements into the view and removing the subset. The only way to know is for you to go to the server, look in the folder called NameofCube_vues and upload the .vue file to this forum so we can look and see what's in there. Absent that it is a waste of time to post any more questions on this board about this. You have not discovered some unknown bug in TM1. Attaching views to subsets and editing those subsets later works perfectly fine in TM1.

Posted: **Thu Aug 06, 2015 2:21 pm**

You are right Tomok. ı m not permitted to get that file but l will talk with the IT guy and try to take it.

I checked on my VM . and ı find the file name is 'BDDK_Dipnotlar}vues'
and inside of this file has all the views .vue files is one of them ok for you or you want 'BDDK_Dipnotlar}vues' file which has all the views's vue file?

Thanks for reply..

Posted: **Thu Aug 06, 2015 3:25 pm**

AliUgur wrote:I checked on my VM . and ı find the file name is 'BDDK_Dipnotlar}vues'

That's not a file, it's a folder. What you haven't mentioned in your posts is whether the view and subsets are private or public. If you mix and match it can make a huge difference. Perhaps you are editing a private subset, thinking it is a public one or vice versa.

Posted: **Fri Aug 07, 2015 8:43 am**

I added the .vue folder which my all views's vue file have it. But as ı checked. I saw someting like that.

First, after you said about .vue files ı checked on my VM first and my public subset have different element than my .vue file date element.

And after that, ı reached the server's .vue folder and file(ı attached that here). On the server, it changed. Cause, once ı changed my public date subset and saved all the views with that subset thats why ıt does not matter what ı put on my public subset I think. So do you guys have any idea how to fix it?

Posted: **Fri Aug 07, 2015 9:58 am**

AliUgur wrote:I added the .vue folder which my all views's vue file have it. But as ı checked. I saw someting like that.

First, after you said about .vue files ı checked on my VM first and my public subset have different element than my .vue file date element.

And after that, ı reached the server's .vue folder and file(ı attached that here). On the server, it changed. Cause, once ı changed my public date subset and saved all the views with that subset thats why ıt does not matter what ı put on my public subset I think. So do you guys have any idea how to fix it?

Actually... you may have stumbled upon an unintentional consequence of something that IBM did in the 10.x series. Specifically, they changed the format of the .vue files.

When I did my tests I did them on 9.5.2, which is my production version. As I noted saving the subset changed the view automatically.

In both versions there is a block in the .vue file which starts at 373, followed by a number representing the number of title dimensions.

In 9.5.2 there is then a list of integers which tells you which member of the title subset is the active one. In my case:

Code: Select all

So I have 10 title dimensions. The second one has the 6th element selected, all of the others have the first element selected.

Consequently in 9.5.2 when I changed the order of the subset so that the new element was the first one, it was the one selected.

But in 10.2, the exact same view of the exact same cube looks like this:

Code: Select all

373,10
1,Actuals Vs Budget
6,Final
1,AUD
1,Mon
1,Total Entities
1,01
1,Total Projects
1,Total Departments
1,Total Products
1,Monetary

That is, the selected element is specified by index and by name. And it appears that if there is a conflict, the name wins over the index.

Based on my tests, the only way you get the new element selected in the view is if the old one isn't there any more. Even deleting the element from the subset, resaving the subset, then adding it back to the subset makes no difference because, you guessed it, changing the subset doesn't change the hard coding of the selection name in the frappin' .vue file.

I'm sure that someone thought that this was an improvement.

Can anyone else confirm this? Methinks that an RFE might be needed on this one, because I honestly can't see how on earth the problem can be solved when someone has hundreds of views (as is the case here) without having TI tear them down and rebuild them. This completely blows to hell what used to be a powerful way to update dozens of views in a stroke. (Though it still works if the original element is simply replaced by another one, with the old one no longer in the subset. In such a case the view has no choice but to use the index position rather than the name, since the name is no longer in the subset.)

Posted: **Sun Aug 09, 2015 5:01 pm**

Hi Alan

My VM's TM1 version is 10.2.2 . When ı try this action on my VM Works perfectly. But at the bank it didnt work. But also at the bank tm1 has the 10.2.2. version.

Based on my tests, the only way you get the new element selected in the view is if the old one isn't there any more. Even deleting the element from the subset, resaving the subset, then adding it back to the subset makes no difference because, you guessed it, changing the subset doesn't change the hard coding of the selection name in the frappin' .vue file.

I couldnt understand that what is the problem here. if tm1 versions are problem, both tm1 has the same version.

While it was working on my VM, why it is not working on server. what dou you think about it? Also, what did you tested and you reached that your asnwer's point?

Thanks..

Posted: **Mon Dec 07, 2015 7:34 pm**

Hi guys, I am still having this problem and ı need help asap.. Also , What is RFE Alan?

Posted: **Tue Dec 08, 2015 4:27 am**

AliUgur wrote:Hi guys, I am still having this problem and ı need help asap..

There's nothing much you can do about it; it just seems to be the way they've programmed it to work in the 10.x series. The only option would seem to be to use the "have TI tear down and rebuild the view" approach. If you really have something like 200 views then you may want to consider having a control cube which holds the names of the cubes and the views that you want to do the rebuild for.

AliUgur wrote: Also , What is RFE Alan?

Request For Enhancement; see here.

Don't hold your breath. As with when they changed chore scheduling from local time (probably used by the vast majority of users) to UTC time, IBM will be convinced that any changes that it makes will be for your benefit. Even if they aren't. And they will not budge. (On the other hand some in there did finally come to realise that Performance Muddler was a train wreck, so there may be some hope. But even if the behaviour was changed back, it wouldn't happen any time soon.)

Posted: **Tue Dec 08, 2015 6:45 am**

I wasn't aware of this change to .vue format. It's not like a feature that IBM shouted from the rooftops.
BUT let's be clear that this is a good thing. it means persistence of the title element in the view. That is that the element actually set by the user will still be the title the next time the user opens the view. This is a good thing. (At least in my books). Formerly in the eyes of every end user (and certain admins and developers like me) the old behaviour was wrong in that a dimension update that inserted an element with a lower index than the currently selected element in a view title would break the view. This is not good for usability.

There were some workarounds around this behaviour like dictating that only subsets can be used on all dimensions in saved public views and that for title dimensions the index was always set to 1, but to be honest the fact that view titles were defined by index rather than by element is too esoteric for 99% of users to grasp and this feature always led to issues.

Yes there will always be exceptions where the old way was quicker for certain tasks. But in the big majority of use cases I hope we can agree that the new implementation is safer and therefore better as the previously saved title element doesn't get randomly changed due to a dimension or subset update.

If a title subset contains only one element then no change to behaviour. If a bulk update of title elements is needed then it may require more work but having a string cube to hold the title dimension names, subset names and title elements may actually be a pretty good idea for ongoing maintenance and once that pretty simple cube is built then the bulk maintenance should be at the click of a TI button.

Posted: **Tue Dec 08, 2015 8:12 am**

lotsaram wrote:I wasn't aware of this change to .vue format. It's not like a feature that IBM shouted from the rooftops.
BUT let's be clear that this is a good thing. it means persistence of the title element in the view. That is that the element actually set by the user will still be the title the next time the user opens the view.

This is a good thing. (At least in my books). Formerly in the eyes of every end user (and certain admins and developers like me) the old behaviour was wrong in that a dimension update that inserted an element with a lower index than the currently selected element in a view title would break the view. This is not good for usability.

Agreed when the subset powering the title element is the default one. But not when it's a named subset.

lotsaram wrote:There were some workarounds around this behaviour like dictating that only subsets can be used on all dimensions in saved public views and that for title dimensions the index was always set to 1, but to be honest the fact that view titles were defined by index rather than by element is too esoteric for 99% of users to grasp and this feature always led to issues.

Yes there will always be exceptions where the old way was quicker for certain tasks. But in the big majority of use cases I hope we can agree that the new implementation is safer and therefore better as the previously saved title element doesn't get randomly changed due to a dimension or subset update.

I'm afraid that we shall not so agree.

In my view (no pun intended) the use of named subsets is a powerful tool to automatically update very large numbers of public views instantaneously. The most obvious example of this is with a time dimension where you may (and I am not speaking theoretically in my own case) want the subset to consist of last period / current period / next period with current period selected. (This is not a mile away from the situation described by the original poster either.) Previously you could update the subset and have all views automatically open to the correct element. Now you're screwed, the prior period element will be the one selected until it drops out of the subset.

Though I concede that it's less of an issue for end users using websheets and the like where the index can be specified in the SubNm formula. Certainly this is not a disastrous change, and I think that it was probably implemented for the reasons that you specified. But if they were going to make a change like this I'd much rather that they limit it to unnamed subsets. End users may not always have their head around indexes but admins do, and it's admins who will be publishing public views. IMHO that control should not have been taken out of their hands.

But all that said... I think you're right that on balance the good from this change will outweigh the bad. As I said, I'd just have preferred that the change be a tad more discriminating in its application.

TM1 Forum

TM1 View problem

TM1 View problem

Re: TM1 View problem

Re: TM1 View problem

Re: TM1 View problem

Re: TM1 View problem

Re: TM1 View problem

Re: TM1 View problem

Re: TM1 View problem

Re: TM1 View problem

Re: TM1 View problem

Re: TM1 View problem

Re: TM1 View problem

Re: TM1 View problem

Re: TM1 View problem

Re: TM1 View problem