TM1 Forum

Hello everyone,

I have had one of those TM1 problems which completely baboozeled me! Two users with exactly the same securities(they are both admin's) open the same view on the server and the one gets values and the other one don't.

Any idea why this might happen?

Thank you!

sure they are the same views? no private subsets or views by accident?

par3 wrote:Hello everyone,

I have had one of those TM1 problems which completely baboozeled me! Two users with exactly the same securities(they are both admin's) open the same view on the server and the one gets values and the other one don't.

Any idea why this might happen?

Any rules involved? Any feeders that might not be working?

They are exactly the same views. No private subs etc.

The feeders ands rules are working. If I for example open the view there is no problem either.

In some versions there can be confusion about the private default views and subsets.

If user A has no private defaults then he will see the public default
If user B has a private default then they will see the private default _even_ if they select the public default.

If they are looking at exactly same data point at the same time and they are seeing different results, then at a guess the only sensible explanation is they are looking at different servers...

Not sure what to suggest. Try getting them to log in as each other, get them to slice the view and mail to you and have a look at the results. They might just _think_ they are looking at the same data point??
HTH

Here are the 2 screenshots they sent me. Maybe this may help.

par3 wrote:Here are the 2 screenshots they sent me. Maybe this may help.

Not that this SHOULD matter, but I note that one has automatic calculation on and the other doesn't. (It's the only difference that I can see between the two, though I can't see the title bar.) It'd be interesting to see whether they get the same result if they turn auto recalc off.

Maybe you have some kind or problem with alias that are out of sync?

One shot shows 91590 and the other 091590, so the two views may not be looking at the same bit of the cube?

Cheers

Steve Rowe wrote:Maybe you have some kind or problem with alias that are out of sync?

One shot shows 91590 and the other 091590, so the two views may not be looking at the same bit of the cube?

Ooops, missed that one. That's what I get for posting while lying in bed not getting any sleep with a dose of 'flu.

One does wonder how it would be possible for the same view to use two different aliases...

Hello,

Do you have 2 elements of one called 091590 - Bokomo Cereals and the other 91590 - Bokomo Cereals. See if the user that can not see the numbers can see both elements?

Also examine that both users are in the same security group?

its the cereals selection, they are not the same. there must be 2 elements, one with the leading zero and one without. i've had the same issue with clock numbers for employees, i ended up using a different unique identifier because of all the issues it caused.

have a try to use "NUMBR" in your TI process to get rid of the leading Zero.

NUMBR converts a string to a number.
The string passed to the NUMBR function must use . (period) as the decimal separator and , (comma) as the thousand separator. Any other decimal/thousand separators will cause incorrect results.

NUMBR(string)

unless of course you have valid entries such as 012345 and 0012345, in which case you won't be able to sanitise the data in that way. don't you just love multiple HR systems?