TM1 9.4.1 - wrong values on DBRW

[gabi]

Hello,

Few months ago we found the "wrong values on DBRW" on TM1 9.4.1 FP2 and reported to IBM.
The DBRW bug was rare and random so testing the HF16 for that bug was Impossible.
We implemented HF16 (Server and clients) to resolve the DBRW bug according IBM support solution.

Now, the BUG appears again on TM1 9.4.1 FP2 HF16.\
Is there anyone else encountered this BUG? Do you know if 9.4.1 FP3 solved that BUG with a better fix?

Thank you,
Gabi

[kpk]

Hello,

Could you check the same slice from the admin user?
I can see a private view in your doc.

Regards,
Peter

[lotsaram]

Usually when this happens it is due to one of two things as opposed to a rare and difficult to track down bug.

1/ The client Excel session has been used to log on as several different users and has become "somewhat confused"
2/ The client's Excel session was open in a previous server session (i.e. the user has not shut down Excel but for whatever reason a TM1 restart has occurred in the interim)

The fixes in both cases are the same, either restart the Excel session and perspectives or run the M_Clear TM1 macro.

If that works then you have Occam's Razor in action; always look for the most likely explanation first. If that doesn't fix it and the incorrect sliced values apply to all client sessions and not just particular sessions where points 1 or 2 above apply and the only fix is a full TM1 server restart then you probably do have yourself a "rare and random bug."

[Steve Rowe]

Irrespective of the reasons this a major fail from IBM, how can you put a client out there that you can not rely on delivering the correct results 100% of the time? Does it fails quietly too so you don't even know you are looking at the incorrect figures? Awful...

I can just imagine explaining to my users,
"oh btw sometimes TM1 will tell you the wrong information but don't worry about it just restart Excel when it happens."
User : " Errrr, OK so what you mean is TM1 doesn't work and we shouldn't use it."
Me : "No, it's just that sometimes it get's confused."
User : "What?? How can a computer get confused, it's not a person. You mean it's broken don't you?"
Me : "Errrr, No not exactly, it's just that sometimes it won't tell you the right answer"
User : "So how's that different to broken and how can I tell if it's not working?"
Me : *scrunchs crisp packet* "I might be just about to go through a tun..." *click*

Bring back 714!

[Paul Segal]

Bring back 7.14!

Wouldn't help much, at least on lotsaram's second point, as 7.14 had been known to do the exact same thing.

[gabi]

Hello,

Could you check the same slice from the admin user?
I can see a private view in your doc.

Regards,
Peter

It's not a saved view - It's slice and dice of the default view.
I can't reproduce this bug as It's rare and random - That's the big problem as I can't tell the users how to avoid it or advice them to manually check any value in Excel reports.

[kpk]

It's not a saved view - It's slice and dice of the default view.
I can't reproduce this bug as It's rare and random - That's the big problem as I can't tell the users how to avoid it or advice them to manually check any value in Excel reports.

I asked it because there was a client where something similar occurred some years ago.
I am not sure what was the exact situation. Maybe it was a bit different and the DBRW Excel was published to TM1web.

The reason for the data inconsistency was that dimension element level security was implemented for one of the page dimensions and when the user selected an element on the sheet (or the websheet?) TM1 retrieved value for an other element but showed the selected element in the SUBNM cell.

Therefore my questions:
- Are you sure that any of you have experienced this issue with the Admin user as well?
- Do you have a security restriction for any of the title dimensions?

If the reason for your issue is something similar then you can reproduce the bug testing a non admin user with NONE, Write, Read level elements.

Regards,
Peter