Zero Suppression not surpressing the zeros

[ABEX_BE]

Dear,

I'm having a small problem with zero suppression. The thing is that TM1 is not surpressing all the zeros in my cube. My feeders are probably working fine, but it seems that once a cell received a value in the past and was also correctly fed, TM1 keeps remembering that a value has been in that cell and thinks it is still in there, even though I have deleted the input for that cell and it is back to zero. So normally when I would do zero surpression, TM1 shouldn't show me that row, but it's still showing even though everything is absolutely zero. Has someone ever came across this as well? Any suggestions on how to fix this?

Thanks for the help, much appreciated.

Kind regards,
Albrecht

[tomok]

Feeders don't "go away" until the TM1 service is restarted. So, if you are trying to zero-suppress a rule calculated cell that has been fed the only way to "unfeed" is going to be to restart the services. Also, if you are using persistent feeders then you will also need to reprocess the feeders, either by re-saving the rule file or via a TI function call, before you restart.

[rmackenzie]

CubeUnload should drop the feeder flags if you don't want to restart the service. Beware though, that all the cached values are dropped too so the next time the user requests the view, unless you've reprocessed the feeders then the view may not properly show the consolidated results. If your particular cube is fed from one or more other cubes then you'll need to do the unloading and reprocessing in a particular order in order to get the view back the way you want it.

[ABEX_BE]

Hey guys,

Thanks for input. However, I tried both suggestions and it is still showing me a number of zero-rows, which shouldn't be there. I'm absolutely baffled. None of my colleagues (with a lot of TM1 experience) know what to do here or where this is coming from. Do you have any other suggestions on actions I could undertake?

Thanks again for the help.

Kind regards,
Albrecht

[tomok]

Hey guys,

Thanks for input. However, I tried both suggestions and it is still showing me a number of zero-rows, which shouldn't be there. I'm absolutely baffled. None of my colleagues (with a lot of TM1 experience) know what to do here or where this is coming from. Do you have any other suggestions on actions I could undertake?

If you restarted the TM1 service and immediately thereafter pulled up the view in question and still see rows or columns that have zeros all the way across then this little nugget:

My feeders are probably working fine

is probably not accurate.

Have you tried Check Feeders. If you right-click on a rule calculated cell and it doesn't say "not fed" then it has been fed. Once again, if this is the behavior immediately after restarting the TM1 service, then your feeders are not "probably working fine". If I were you this is where I would spend my time.

[rmackenzie]

My feeders are probably working fine

is probably not accurate.

Another issue you could be facing is that TM1 will sometimes fail to properly store zero in consolidations (both natural and those aggregating rule calculations). See here, here and here for further information.

[Steve Rowe]

I think the feeders working or not and their state is a red herring. A cell that = 0 will always be suppressed in the cube viewer irrespective of the cells fed state. Not sure why I've a different view to others....pretty sure I'm right. If fed cells that = 0 broke zero suppression then on the many occasions that slight over feeding is required I would have noticed it in cube viewer results?

Where are you seeing the behaviour? Are the cells string or numeric? I've found that string cells seem to misbehave in suppression if they have had input and then its removed. Any chance of a screenshot?

Cheers,

[Duncan P]

If SKIPCHECK is specified and if AllRuleCalcStargateOptimization=F (or not specified) then suppression will be on the basis of raw non-zero (or recently zeroed) leaf cells, fed rule-calculated leaf cells and consolidated cells with at least one non-zero or fed leaf descendant.

When the option is false the suppression happens before the calculation and so it is not possible for the zeroness of the actual calculated values to contribute to the results.

If the option is set to true it actually checks the values. However the performance characteristics of the optimisation are interesting. YMMV.

[EDIT] I strongly suspect that I have been, in part, communicating through my posterior. I am correctly recalling instances where zero-suppressed views had rows or columns of all zeroes. However they were all rule-calculated at consolidated level so the only thing I can say for sure is that C level cells that calculate to zero, but that are validly fed, are still included. I believe that, in order to determine whether to feed ancestors, calculations are done at the leaf level during the set-up of the view. I do not know whether fed zero leaf cells will be included - I suspect not - which is probably where Steve is coming from.

Perhaps someone who still has access to the product - that's all the rest of you - could do some experiment and report back.

[java_to_tm1]

once a cell received a value in the past and was also correctly fed, TM1 keeps remembering that a value has been in that cell and thinks it is still in there, even though I have deleted the input for that cell and it is back to zero

This stinks of UNDEFVALS...
Alex: do you have undefvals; in your rule file?