Users not getting the same data.

[par3]

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!

[Steve Vincent]

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

[Alan Kirk]

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?

[par3]

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.

[Steve Rowe]

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

[par3]

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

[Alan Kirk]

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.

[Steve Rowe]

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

[Alan Kirk]

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...

[Herman Moller]

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?

[Steve Vincent]

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.

[Byron Hsu]

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)

[Steve Vincent]

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?