TM1 Forum

This is more a case of idle curiosity than anything since I'm convinced that it's a version-specific (8.2.12) bug, though I can't find a reference in the release notes to it having been fixed.

The rule is a simple one: The feeder is equally simple: 81010 was the old account, 81500 was the new one, and the values for non-Actuals were kept for historical reasons that I shan't go into here. Since the old numbers are now a number of years old we're going to be shutting down the old accounts and transferring the data to the new ones.

However when my assistant took the rules out... 81500 retained the original value from 81010. When you right click on the value it no longer shows Trace Calculation as an option, it can be edited, naturally... yet the value of 81010 still appears in 81500's cell.

This doesn't occur in 9.1 SP4; there if you delete the rule, the value goes away. Add the rule back, it reappears. Comment out the rule, it goes away and so on.

But in 8.2.12, the only way you can get rid of the value is by manually obliterating it.

Does anyone remember encountering this behaviour and / or when it was fixed?

Hello,

Have you tried to unload the cube after deleting the rule?

Regards,

Peter

kpk wrote: Have you tried to unload the cube after deleting the rule?

Sorry, I should have included that in the original post.

Not only did we try unloading the cube, we even tried bouncing the server.

Definitely bug-city here.

I've seen that before.

Not sure if it's the case with your model, but i had a cube with data in it (via TI) that i then "replaced" with some rules. At a later date i removed the rules and data still appeared in the cube, it seems the .cub retained the values even tho it was being overwritten by the rule. Confused the life out of me as a feeder was working on some cells and not others, turned out the cells with data fed fine by any new ones created by the rule were being missed.

Not sure if that was 8.1.8 or 9.0 but i think it's likely to happen in all versions...

I have encountered that one the past as well Steve. As far as I remember it is not classified as a bug. It has something to do with the way that once you switch skipcheck on it manages the flag in the .cub. I can only suggest a) checking to see if the data matches that created by the rule and b) archiving the data to file and removing it,

Jim.

jim wood wrote:I have encountered that one the past as well Steve. As far as I remember it is not classified as a bug. It has something to do with the way that once you switch skipcheck on it manages the flag in the .cub. I can only suggest a) checking to see if the data matches that created by the rule and b) archiving the data to file and removing it,

Thanks for the comments all; we ended up doing what Jim suggested anyway. (The data did match, and we did archive it and overwrite it.)

However classified as a bug or not, the behaviour is definitely different between 8.2.12 and 9.1 SP4; I tested it with exactly the same cube from the same data directory (or more precisely a copy thereof). In 9.1 SP4, the data is, shall we say, "non-persistable". (To my mind this is a good thing.) Based on Steve's experience of it happening in 9.0, the change may well have been at the 9.1 upgrade.

When I used to work for Applix we were on version 8. (Just) It might be that the way this works has changed since, hence the change in behaviour,

Jim.

We had this same problem (V8.2.12) or similar. An overhead populated by an FTE or STET'd if empty. When the FTE is removed the overhead stays. This does not always happen, and we never worked out why. After upgrading (9.1.3) we still have the problem, so I just wrote a TI that runs every night to clear the values out.